Identifying fraudulent instruments and identification

ABSTRACT

In a computer-implemented method, a digital image of a signed financial instrument or identification card may be received from a financial institution or merchant computing terminal. The digital image may be analyzed to identify a type of financial instrument or identification card, and an originating entity. Expected fields of the instrument or card may be determined based upon the type and the originating entity. The digital image may be analyzed to identify actual fields on the instrument or card, and it may be determined whether the expected fields match the actual fields to determine whether a fraudulent field exists on the signed financial instrument or identification card. If it is determined that no fraudulent field exists, additional operations may be performed to determine whether the instrument or card contains fraudulent characters or content.

CROSS-REFERENCE TO RELATED APPLICATIONS

This claims the benefit of U.S. Patent Application No. 62/313,196, filedon Mar. 25, 2016 and entitled “Reducing Financial Fraud Using MachineLearning and Other Techniques,” U.S. Patent Application No. 62/318,423,filed on Apr. 5, 2016 and entitled “Reducing Financial Fraud UsingMachine Learning and Other Techniques,” U.S. Patent Application No.62/331,530, filed on May 4, 2016 and entitled “Reducing Financial FraudUsing Machine Learning and Other Techniques,” and U.S. PatentApplication No. 62/365,699, filed on Jul. 22, 2016 and entitled“Detecting and/or Preventing Financial Fraud Using Geolocation Data,”the disclosures of which are hereby incorporated herein by reference intheir entireties.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to financial fraud and, morespecifically, to processing techniques for automatically detectingdocument-related fraud.

BACKGROUND

Financial fraud, in its many forms, is a problem of enormous magnitudeand scope, causing billions of dollars in economic losses and impactingmany millions of people. Types of financial fraud include use of a lostor stolen card, account takeover, skimming, chargeback (“friendly”)fraud, counterfeiting, forgeries and application (e.g., loanapplication) fraud, to name just a few. The problem only continues togrow as various technological advances, intended to improve convenienceand efficiency in the marketplace, provide new opportunities for badactors. For example, an ever-increasing amount of fraud may be linked toonline transactions made via the Internet.

Various software applications have been developed to detect potentiallyfraudulent transactions. For example, dollar amounts and geographiclocations have generally been used to flag particular credit or debitcard transactions, with cardholders then being contacted by employees ofthe card issuer to determine whether the transactions were indeedfraudulent. To ensure that most instances of fraud are captured,however, such techniques generally have a low threshold for triggering afraud alert. As a result, numerous fraud alerts are false positives. Theprevalence of false positives leads to a large cost in terms of thedrain on human resources (e.g., calling customers to discuss eachsuspect transaction, and/or other manual investigation techniques), andconsiderable distraction or annoyance for cardholders. To provide asolution to these shortcomings in the field of automated frauddetection, innovative processing techniques capable of reducing falsepositives are needed.

Other conventional processes relating to financial fraud are likewiseresource-intensive. For example, efforts to combat counterfeiting offinancial or other documents (e.g., personal checks, identificationcards used to obtain loans, etc.) may be typically limited totime-consuming and error-prone human review (i.e., the “eye test”).

BRIEF SUMMARY

The present embodiments may, inter alia, use new processing techniquesto determine whether physical documents relating to a financialtransaction (e.g., personal checks, identification cards, etc.) arefraudulent (e.g., counterfeit and/or forged) and/or should be flaggedfor further review.

In one embodiment, a computer-implemented method of identifyingfraudulent transactions, financial instruments, or fraudulentidentification cards may include: (1) receiving, by one or moreprocessors, a digital image of a signed financial instrument oridentification card from a financial institution or merchant computingterminal; (2) analyzing, by the one or more processors, the digitalimage to identify (i) a type of financial instrument or identificationcard, and (ii) an originating entity of the signed financial instrumentor identification card; (3) determining, by the one or more processors,the expected fields of the signed financial instrument or identificationcard based upon the type, and the originating entity; (4) analyzing, bythe one or more processors, the digital image to identify actual fieldson the signed financial instrument or identification card; (5)determining, by the one or more processors, whether the expected fieldsmatch the actual fields on the signed financial instrument oridentification card to determine whether a fraudulent field exists onthe signed financial instrument or identification card; and/or either(6A) in response to determining that a fraudulent field does exist onthe signed financial instrument or identification card, (i) generating,by the one or more processors, an electronic notification indicatingthat a fraudulent field exists on the signed financial instrument oridentification card, and (ii) transmitting, by the one or moreprocessors and one or more transceivers, the electronic notification tothe merchant computing terminal to provide notice of the fraudulentfield, or (6B) in response to determining that a fraudulent field doesnot exist on the signed financial instrument or identification card, (i)determining, by the one or more processors, allowable content, or anallowable range of content or characters, for the expected fields, (ii)analyzing, by the one or more processors, the digital image to identifyactual characters or content within the actual fields on the signedfinancial instrument or identification card, (iii) comparing, by the oneor more processors, the actual characters or content within an actualfield with the allowable content, or the allowable range of content orcharacters, for the corresponding expected field to determine whetherfraudulent characters or content are in an expected field, (iv) inresponse to determining that fraudulent content exists in an expectedfield, generating, by the one or more processors, an electronicnotification detailing the fraud or why the financial instrument oridentification card is suspicious, and (v) transmitting, by the one ormore processors and one or more transceivers, the electronicnotification to a computing device of a financial institution ormerchant at which the signed financial instrument or identification cardis being presented to provide notice of fraudulent characters orcontent. The method may include additional, less, or alternate actions,including those discussed elsewhere herein.

In another embodiment, a computer system for identifying fraudulenttransactions, financial instruments, or identification cards includesone or more transceivers and one or more processors configured to: (1)receive, via the one or more transceivers and one or more radio links, adigital image of a signed financial instrument or identification cardfrom a financial institution or merchant computing terminal; (2) analyzethe digital image to identify (i) a type of financial instrument oridentification card, and (ii) an originating entity of the signedfinancial instrument or identification card; (3) determine the expectedfields of the signed financial instrument or identification card basedupon the type, and the originating entity; (4) analyze the digital imageto identify actual fields on the signed financial instrument oridentification card; (5) determine whether the expected fields match theactual fields on the signed financial instrument or identification cardto determine whether a fraudulent field exists on the signed financialinstrument or identification card; and/or (6) in response to determiningthat a fraudulent field does not exist on the signed financialinstrument or identification card, (i) determine allowable content, oran allowable range of content or characters, for the expected fields,(ii) analyze the digital image to identify actual characters or contentwithin the actual fields on the signed financial instrument oridentification card, (iii) compare the actual characters or contentwithin an actual field with the allowable content, or the allowablerange of content or characters, for the corresponding expected field todetermine whether fraudulent characters or content are in an expectedfield, (iv) in response to determining that fraudulent content exists inan expected field, generate an electronic notification detailing thefraud or why the financial instrument or identification card issuspicious, and (v) transmit, via the one or more transceivers, theelectronic notification to a computing device of a financial institutionor merchant at which the signed financial instrument or identificationcard is being presented to provide notice of fraudulent characters orcontent. The computer system may include additional, less, or alternatefunctionality, including that discussed elsewhere herein.

In another embodiment, a non-transitory, computer-readable medium storesinstructions that, when executed by one or more processors, cause theone or more processors to: (1) receive a digital image of a signedfinancial instrument or identification card from a financial institutionor merchant computing terminal; (2) analyze the digital image toidentify (i) a type of financial instrument or identification card, and(ii) an originating entity of the signed financial instrument oridentification card; (3) determine the expected fields of the signedfinancial instrument or identification card based upon the type, and theoriginating entity; (4) analyze the digital image to identify actualfields on the signed financial instrument or identification card; (5)determine whether the expected fields match the actual fields on thesigned financial instrument or identification card to determine whethera fraudulent field exists on the signed financial instrument oridentification card; and/or (6) in response to determining that afraudulent field does not exist on the signed financial instrument oridentification card, (i) determine allowable content, or an allowablerange of content or characters, for the expected fields, (ii) analyzethe digital image to identify actual characters or content within theactual fields on the signed financial instrument or identification card,(iii) compare the actual characters or content within an actual fieldwith the allowable content, or the allowable range of content orcharacters, for the corresponding expected field to determine whetherfraudulent characters or content are in an expected field, (iv) inresponse to determining that fraudulent content exists in an expectedfield, generate an electronic notification detailing the fraud or whythe financial instrument or identification card is suspicious, and (v)transmit the electronic notification to a computing device of afinancial institution or merchant at which the signed financialinstrument or identification card is being presented to provide noticeof fraudulent characters or content.

BRIEF DESCRIPTION OF THE DRAWINGS

The Figures described below depict various aspects of the systems andmethods disclosed herein. It should be understood that each Figuredepicts an embodiment of a particular aspect of the disclosed systemsand methods, and that each of the Figures is intended to accord with apossible embodiment thereof.

FIG. 1 depicts an exemplary environment in which techniques for frauddetection, verification and/or classification may be implemented,according to one embodiment.

FIG. 2 depicts an exemplary process flow for machine learning of frauddetection, verification and/or classification rules, according to oneembodiment.

FIGS. 3A-3F depict exemplary process flows for machine learning ofparticular types of fraud detection, verification and/or classificationrules, according to different embodiments.

FIGS. 4A-4F depict exemplary factors and algorithms that may be used inconnection with various fraud detection, verification and/orclassification rule sets, according to different embodiments.

FIG. 5 depicts a flow diagram of an exemplary method for facilitatingthe detection of document-related fraud, according to one embodiment.

FIGS. 6 and 7 illustrate exemplary computer-implemented methods ofidentifying potential fraud associated with financial instruments oridentification cards based upon digital image analysis and/or machinelearning techniques.

FIG. 8 depicts an exemplary computer system in which the techniquesdescribed herein may be implemented, according to one embodiment.

DETAILED DESCRIPTION I. Exemplary Fraud Detection and/or Classification

The embodiments described herein relate to, inter alia, wholly orpartially automated detection, verification and/or classification offinancial fraud. For ease of explanation, and unless otherwise clearlyindicated by the context of usage, “detecting” or “determining” fraudmay be used herein to refer to initially flagging fraudulent (orpotentially fraudulent) activity, to verifying/confirming thatsuspect/flagged activity was indeed fraudulent, or generally to both.The systems and techniques described herein may be used, for example, toidentify, prevent and/or quantify/measure instances of lost or stolencard use, account takeover, counterfeiting, skimming, chargeback(“friendly”) fraud, collusive merchant fraud, application (e.g., loanapplication) fraud, mortgage fraud, and/or one or more other types offraud relating to existing and/or potential financial transactionsand/or accounts. Moreover, those skilled in the art will appreciate thatat least some of the technical advancements described below (and/orshown in the accompanying figures) are not necessarily restricted to thefinancial field.

In some embodiments, a fraud detection and/or classification system mayanalyze data relating to a number of existing or potential financialaccounts. The analysis/processing may be performed in batch processingoperations, or substantially in real-time (e.g., as the data isgenerated and/or as financial transactions occur, etc.), and the datamay be obtained from a variety of sources based upon the particularembodiment and/or scenario. In one embodiment, for example, data fromfinancial account records may be analyzed, along with data indicatingonline activity of an account holder, location data (e.g., globalpositioning satellite (GPS) data from a smartphone or vehicle of theaccount holder) and/or other data, to determine whether a particularfinancial transaction was fraudulent or likely fraudulent. The analysismay be performed automatically after the transaction has been made, ormay be performed in response to a person or algorithm flagging thetransaction as a potentially fraudulent one, for example.

The analysis may include determining whether the account holder hasexpressed interest in the object (e.g., product or service) of thetransaction or the merchant, and/or determining whether the transactionis consistent with spending patterns associated with the account holder(e.g., spending patterns identified using the account holder'stransaction records), for example. In the case of multiple accountholders (e.g. multiple credit or debit card holders), accuracy may beimproved by identifying spending patterns at the individual level ratherthan, or in addition to, at the aggregate account level. For example, amaximum amount of money typically spent in a single transaction (e.g.,over the course of a one-month window, etc.) may be determined for eachof two cardholders listed on a single account, and the maximum amountfor the cardholder who purportedly made a particular purchase may becompared to the purchase amount to determine whether fraud is suspected.

In another exemplary embodiment, financial transaction data may beanalyzed to determine whether a chargeback payment from the merchant oracquiring bank to a card issuer may be appropriate in connection with aparticular fraudulent transaction. For example, the card informationentry mode (e.g., collecting card information by inserting the card in achip reader, swiping the card, manually entering the card information,etc.), the transaction amount, the similarity to other transaction(s),and/or other information may be used to identify which fraudulenttransactions are relatively strong chargeback candidates. The analysismay be performed in response to a cardholder reporting the transactionas fraudulent, or after a card issuer has confirmed that the transactionwas fraudulent, for example. For the subset of instances where afraudulent transaction has been identified as a chargeback candidate, afull set of chargeback rules (e.g., devised by a card network entitysuch as VISA®, Mastercard®, American Express®, Discover®, etc.) may bemanually or automatically applied to determine whether a chargebackprocess should be initiated (or continued).

In another exemplary embodiment, application data (e.g., informationentered in fields of an online application) may be analyzed inconjunction with search terms entered by a user at a computing device(e.g., the device from which the user submitted the applicationinformation) to determine whether the person proffering the applicationis not the person that he or she purports to be. For example, if theperson submitting an application had previously used an Internet-basedsearch engine to search for results associated with the purportedapplicant's name (e.g., by using the name as a search term, possibly inaddition to other terms such as “address” and/or “employer,” etc.), theapplication may be flagged for suspected fraud, and subjected toadditional steps of manual and/or automated review.

In another exemplary embodiment, a fraud dispute resolution process(e.g., after a customer has reported a fraudulent or unrecognizedtransaction associated with his or her account) may be facilitated usingmachine learning techniques. For example, a machine learning program maybe trained, using past dispute resolution interactions with customersand the associated outcomes (fraud determinations), to identify varioustypes of information that, if elicited from customers, tend to beindicative of fraud or the absence thereof. When fraud is suspected fora particular transaction, one or more queries for the individualpurportedly making the transaction may be automatically generated usingthe types of information identified by the machine learning program, aswell as information about the suspect transaction and/or relatedtransactions (e.g., dates, locations, amounts, etc.). In someembodiments and/or scenarios, responses to the queries may be collectedand analyzed to automatically generate additional queries, with the endgoal of discerning whether the transaction was authorized. For example,queries may include asking whether a cardholder recalls particular othertransactions that appear on the cardholder's account and were madearound the same time as the suspect transaction (and/or from the samemerchant), asking whether the cardholder recalls being in a particularlocation at a particular time (e.g., a location associated with anothertransaction appearing on the cardholder's account), whether thecardholder is aware of a particular billing alias used by a merchant,and so on.

In another exemplary embodiment, image data corresponding to aparticular physical document (e.g., a personal or cashier's check, adriver's license or other identification card, etc.) may be analyzed,using rules generated by a machine learning program, to determinewhether the document is, or may be, fraudulent (e.g., a counterfeitdocument, and/or a document that includes forged contents). For example,the machine learning program may be trained using images of multipleother documents, and fraud determinations made in connection with thoseother documents. The machine learning program may learn which rangesand/or tolerances for dimensions, fonts, colors, patterns, etc., tend tobe most indicative of counterfeiting, for example. A forgery may bedetected based upon factors relating to the contents of various fieldsin a document, such as whether handwriting, a signature, and/or a dateformat (e.g., “Jan. 1, 2016,” “1/1/16,” etc.) matches that used forother personal checks from a particular account holder, for example. Thefraud determination may be made substantially in real-time to provide awarning, if needed, to a merchant making a sale, for example, or may beused to flag a relatively small number of documents for physical reviewat a later time, etc.

In another exemplary embodiment, machine learning techniques may be usedto analyze financial transactions for purposes of classifyingpotentially fraudulent behavior (e.g., “counterfeiting,” “skimming,”“lost or stolen card,” etc.). For example, the machine learning programmay be trained using fraud classifications made in connection withmultiple other financial accounts. The machine learning program maylearn which types of data tend to be indicative of differentclassifications (e.g., transaction amount, credit card information entrymode, particular types of online activity data, etc.), and/or which datavalues tend to be indicative of different classifications (e.g.,transactions over $10,000, manual card number entry, etc.), for example.Once a class of potential fraud has been identified for a particulartransaction, the classification may be used to facilitate or guide afurther, more in-depth analysis or investigation. Alternatively, or inaddition, the classification may be used to calculate one or moremetrics indicating the prevalence of that type of fraud.

By replacing conventional processing techniques with one or more of theprocessing techniques described herein, problems that have beset thefield of fraud detection, classification and/or prevention in the pastmay be greatly mitigated or eliminated. For example, information thathas conventionally been overlooked or ignored may be used to moreaccurately detect, prevent and/or classify fraud, and/or to reduce falsepositive fraud alerts. As another example, a significant amount of timemay be saved by removing the need for manual investigations, or byreducing the number of instances where manual investigations arerequired.

II. Exemplary Environment for Implementing Fraud Detection and/orClassification Processing Techniques

FIG. 1 depicts an exemplary environment 10 in which techniques for frauddetection and/or classification may be implemented, according to oneembodiment. The environment 10 may include an anti-fraud services system(AFSS) 12, a financial account management system (FAMS) 14, a cardnetwork computing system 16, a number of cardholder computing devices20, a number of merchant computing systems 22, a number of other sources24, and a network 26. It is noted that, in other embodiments and/orscenarios, the environment 10 may include more, fewer and/or differentcomponents than those shown in FIG. 1, such as any of those discussedelsewhere herein. For example, the environment 10 may include one ormore additional financial account management systems and/or card networkcomputing systems, and/or one or more of the cardholder computingdevices 20 may instead be a computing device of a holder of a non-cardaccount (e.g., a checking, savings or loan account) or an applicant fora new account (e.g., a new loan account). As another example, theenvironment 10 may include a computing system of one or moreacquiring/merchant banks, and some or all of the communications withmerchant computing systems 22 described below may instead be with theacquiring bank(s).

FAMS 14 may be associated with (e.g., owned and/or maintained by) a bankor other financial entity. For example, FAMS 14 may be a bank that actsas a card issuer associated with a particular type of card network(e.g., VISA®, Mastercard®, etc.), and/or an entity that provides loans(e.g., mortgage, home equity, vehicle, etc.), saving/checking accountservices, and/or other financial services to customers. FAMS 14 maymaintain an account records database 30 that stores various kinds ofaccount information, including account holder information (e.g., names,addresses, etc.) and data indicative of financial transactions made inconnection with each account (e.g., dates, amounts and merchants forcredit or debit card transactions, dates and amounts for customerdeposits and withdrawals, etc.). Account records database 30 may storeaccount information for some or all of the cardholders associated withcardholder computing devices 20, for example. While shown in FIG. 1 as asingle entity within FAMS 14, it is understood that account recordsdatabase 30 may, in some embodiments, be distributed across multipledatabases and/or multiple physical/hardware memories, and/or may bewholly or partially external to (e.g., remote from) FAMS 14.

AFSS 12 may generally provide services that help to detect and/orclassify fraudulent activity in connection with existing and/orpotential (e.g., applied for) financial accounts, such as the accountsmanaged by FAMS 14. In some embodiments, AFSS 12 is included within FAMS14. As seen in FIG. 1, AFSS 12 may include a network interface 32, amemory 34, and a fraud detection/classification unit 36.

Network interface 32 may include hardware, firmware and/or softwareconfigured to enable AFSS 12 to wirelessly exchange electronic data withone or more other components of environment 10 via network 26. Forexample, network interface 32 may include an Ethernet port, a modem, arouter, and/or one or more other ports and/or transceivers for one ormore other wired and/or wireless communication technologies.

Memory 34 may be a computer-readable, non-transitory storage unit ordevice, or collection of units/devices, and may include persistent(e.g., hard disk) and/or non-persistent memory components. Memory 34 maystore instructions that are executable on one or more processors of AFSS12 (not shown in FIG. 1) to perform various operations, including theinstructions of various software applications and data generated and/orused by such applications.

Card network computing system 16 may be a computing system (e.g., one ormore servers) of a credit and/or debit card network entity, such asVISA® or Mastercard®, for example. In some embodiments and/or scenarioswhere the card network entity also acts as the issuer (e.g., AmericanExpress® or Discover®), card network computing system 16 may includeFAMS 14. Card network computing system 16 may provide various servicesto FAMS 14 and/or AFSS 12. For example, card network computing system 16may provide electronic updates to chargeback rules, fraud scores forparticular customers and/or transactions, and so on.

Each of cardholder computing devices 20 may be a computing device of arespective holder of a credit or debit card account managed by FAMS 14.For example, one or more of cardholder computing devices 20 may bedesktop computers, laptop computers, tablet computers, smartphones,smart watches, and so on. The cardholders (e.g., credit or debit cardaccount holders) may use cardholder computing devices 20 to access(e.g., view, modify, etc.) their account information stored in accountrecords database 30 online via network 26. In some embodiments whereAFSS 12 detects and/or classifies activity not related to credit ordebit card fraud (e.g., a fraudulent application for a home equity loan,etc.), cardholder computing devices 20 may instead be computing devicesof other types of customers or potential customers, such as holders ofnon-card-based accounts, or individuals who have submitted an onlineapplication for a loan, etc., as discussed further below. In some ofthese embodiments, the environment 10 may omit card network computingsystem 16.

Each of merchant computing systems 22 may include one or more computingdevices associated with a particular provider of products and/orservices. For example, some or all of merchant computing systems 22 mayinclude servers associated with online retailers. Alternatively, oradditionally, some or all of merchant computing systems 22 may includepoint-of-sale terminal devices providing credit and/or debit cardpayment processing features for “card present” transactions. In someembodiments where AFSS 12 detects and/or classifies activity not relatedto customer purchases (e.g., if AFSS 12 only detects loan applicationfraud, etc.), the environment 10 may omit merchant computing systems 22.

The other sources 24 may include computing devices and/or systemsassociated with sources of one or more other types of information. Forexample, other sources 24 may include vehicle telematics systems (e.g.,installed in vehicles of cardholders associated with cardholdercomputing devices 20), one or more Internet service providers (ISPs)(e.g., ISPs providing Internet access to some or all cardholders),“smart home” system devices (e.g., installed in homes of some or allcardholders), and/or other systems/devices. In some embodiments, theenvironment 10 does not include the other sources 24.

Network 26 may communicatively couple some or all of the componentsshown in FIG. 1. For example, FAMS 14 may use network 26 to communicatewith AFSS 12, card network computing system 16, cardholder computingdevices 20 and/or merchant computing systems 22. As another example,AFSS 12 may use network 26 to communicate with FAMS 14, card networkcomputing system 16, cardholder computing devices 20, merchant computingsystems 22 and/or one or more of the other sources 24. While shown as asingle entity in FIG. 1, network 26 may include multiple communicationnetworks of one or more types (e.g., one or more wired and/or wirelesslocal area networks (LANs), and/or one or more wired and/or wirelesswide area networks (WANs) such as the Internet). Moreover, network 26may use partially or entirely distinct network components to supportcommunications between different endpoints or computing devices, such aswireless communication or data transmission over one or more radiofrequency links and/or wireless communication channels. For example, theportion(s) of network 26 used for communications between FAMS 14 andAFSS 12 may be the same as, or different than, the portion(s) of network26 used for communications between FAMS 14 and one or more of cardholdercomputing devices 20 over one or more radio links or wirelesscommunication channels, or between AFSS 12 and one or more of the othersources 24, etc. Those skilled in the art will appreciate differenttypes of networks that are appropriate for network 26, depending upon,for example, how AFSS 12, FAMS 14 and/or other components of environment10 are localized or distributed across a relatively large geographicarea.

Generally, fraud detection/classification unit 36 of AFSS 12 may detectfraudulent activity, confirm whether suspected or reported fraudulentactivity is truly fraudulent, and/or classify fraudulent or suspectedfraudulent activity. For example, fraud detection/classification unit 36may analyze each transaction stored in account records database 30 todetermine whether that transaction is, or potentially is, fraudulent.Alternatively, fraud detection/classification unit 36 may analyze onlythose transactions that were flagged as possibly being fraudulent (e.g.,by a cardholder calling in to report an unauthorized and/or unrecognizedtransaction, or by FAMS 14 or AFSS 12 generating a preliminary fraudalert after applying an initial set of rules to a transaction, etc.).Fraud detection/classification unit 36 may also, or instead, supportadditional functionality, such as that described below in connectionwith the various components of fraud detection/classification unit 36shown in FIG. 1.

As seen in FIG. 1, fraud detection/classification unit 36 may include amachine learning (ML) rule generator 40, an external data collectionunit 42, a behavior analysis unit 44, a dispute resolution unit 46, achargeback analysis unit 50, an image analysis unit 52, a classificationunit 54, and/or a notification unit 56. In other embodiments, frauddetection/classification unit 36 may include more, fewer and/ordifferent components/units than those shown in FIG. 1. In someembodiments, each of ML rule generator 40, external data collection unit42, behavior analysis unit 44, dispute resolution unit 46, chargebackanalysis unit 50, image analysis unit 52, classification unit 54,notification unit 56, and/or other units or components of frauddetection/classification unit 36 may be a software component stored inmemory 34 and implemented by one or more processors of one or morecomputing devices (e.g., servers) included in AFSS 12.

ML rule generator 40 may generally analyze various types of data togenerate and/or update fraud detection and/or classification rules to beapplied by fraud detection/classification unit 36 and stored in an MLrules database 58. As discussed in further detail below, the rules maybe used to detect and/or classify a single type or category offraudulent activity, or may be used broadly in connection with multipletypes or categories of fraudulent activity. ML rule generator 40 mayimplement any suitable type or types of machine learning. For example,ML rule generator 40 may implement supervised learning techniques, suchas decision trees, regression-based models, support vector machines(SVMs) and/or neural networks, and/or unsupervised learning techniquessuch as Dirichlet process mixture models and/or k-means clustering.Other machine learning techniques are also possible, such as techniquesutilizing Bayesian networks, “deep learning” techniques, and so on.While shown in FIG. 1 as a single entity within AFSS 12, it isunderstood that ML rules database 58 may, in some embodiments, bedistributed across multiple databases and/or multiple physical/hardwarememories, and/or may be wholly or partially external to (e.g., remotefrom) AFSS 12.

External data collection unit 42 may generally collect, via networkinterface 32 and/or from sources internal to AFSS 12, information fromvarious sources (e.g., FAMS 14, cardholder computing devices 20, othersources 24, etc.), and provide that data to other portions of AFSS 12 asneeded (e.g., to ML rule generator 40 to generate and/or update rules,and/or to behavior analysis unit 44, dispute resolution unit 46,chargeback analysis unit 50, image analysis unit 52 and/orclassification unit 54 to detect and/or classify fraudulent activity).Some data may be collected indirectly. For example, FAMS 14 may collecttransaction data from merchant computing systems 22 (and/or fromacquiring banks associated with one or more of merchant computingsystems 22), and external data collection unit 42 may then collect thatdata from the account records database 30 of FAMS 14.

Once an initial set of rules has been generated and stored in ML rulesdatabase 58, those rules may dictate some or all of the types of datagathered by external data collection unit 42. In some embodiments,however, external data collection unit 42 collects a broad set of datatypes that may or may not be relevant to fraud determination orclassification, and ML rule generator 40 continually analyzes that datato determine which data types are most predictive of fraud and/or fraudtype/class.

Behavior analysis unit 44 may generally analyze cardholder-related (orother customer-related) information to identify patterns of behavior,which may then be used by fraud detection/classification unit 36 todetect and/or classify fraudulent activity. For example, behavioranalysis unit 44 may analyze information obtained from account recordsdatabase 30 to identify spending patterns associated with differentcardholders. The operation of behavior analysis unit 44, including thetypes of information analyzed and the ways in which that information isused to arrive at a result (e.g., a pattern of behavior), may bedictated by the rules stored in ML rules database 58.

Data indicative of the behavior patterns identified by behavior analysisunit 44 may be stored in an account holder behaviors database 60, forexample. While shown in FIG. 1 as a single entity within AFSS 12, it isunderstood that account holder behaviors database 60 may, in someembodiments, be distributed across multiple databases and/or multiplephysical/hardware memories, and/or may be wholly or partially externalto (e.g., remote from) AFSS 12. In one embodiment, for example, accountholder behaviors database 60 may be included within account recordsdatabase 30. In still other embodiments, the environment 10 may notinclude account holder behaviors database 60, and behavior patterns maybe only identified by behavior analysis unit 44 “on the fly” as neededby fraud detection/classification unit 36 (e.g., when needed to analyzea transaction in view of past spending patterns of a particularcardholder, etc.).

In some embodiments, behavior analysis unit 44 may separately analyzethe transactions associated with each account holder, even if more thanone account holder exists for a particular account. For example,behavior analysis unit 44 may independently analyze the transactions ofeach cardholder for a credit or debit card account in which each spousehas been issued a credit or debit card in his or her name. Frauddetection/classification unit 36 may then utilize the individualspending patterns when detecting and/or classifying fraud. In oneembodiment where fraud detection/classification unit 36 utilizes adollar amount threshold to detect likely fraudulent transactions, forexample, a first threshold may be used for transactions made by a firstcardholder listed on an account, and a higher, second threshold may beused for transactions made by a second cardholder listed on the account.Further examples are provided below in connection with FIG. 6, accordingto various embodiments. In this manner, fraud detection and/orclassification may be made more precise than would be the case ifspending patterns were only identified at the aggregate level (e.g.,using a single dollar amount threshold, regardless of which cardholdermade a particular transaction).

Dispute resolution unit 46 may generally analyze financial transactiondata and/or other information to automatically generate queries forcardholders or other customers. For example, dispute resolution unit 46may analyze information obtained from account records database 30. Thegenerated queries may be designed to help fraud detection/classificationunit 36 determine whether a particular transaction was fraudulent, orestimate a probability that the transaction was fraudulent, etc. Disputeresolution unit 46 may also process responses fromcardholders/customers, and automatically generate additional queriesbased upon those responses. Examples of the operation of disputeresolution unit 46 are provided below in connection with FIGS. 4E and 9,according to various embodiments.

Chargeback analysis unit 50 may generally analyze financial transactionand/or other information to identify transactions that are goodcandidates for chargeback payments. For example, chargeback analysisunit 50 may analyze information obtained from account records database30 to determine whether there is a relatively high probability that themerchant (or an acquiring bank) should be responsible for a chargebackpayment to a card issuer associated with FAMS 14. The operation ofchargeback analysis unit 50, including the types of information analyzedand the ways in which that information is used to arrive at a result(e.g., flagging a transaction as a chargeback candidate), may bedictated by the rules stored in ML rules database 58. ML rule generator40 may make use of chargeback rules obtained from a card network entity(e.g., from card network computing system 16), and stored in chargebackrules database 62, to generate and/or update the rules applied bychargeback analysis unit 50. Examples of the operation of chargebackanalysis unit 50 are provided below in connection with FIGS. 4B and 7,according to various embodiments.

In some embodiments, transactions flagged by chargeback analysis unit 50are subject to further, manual review using the chargeback rules storedin chargeback rules database 62. In other embodiments, chargebackanalysis unit 50 (or another component of fraud detection/classificationunit not shown in FIG. 1) automatically, with little or no manualinput/assistance, applies the chargeback rules from chargeback rulesdatabase 62 for each flagged transaction. While shown in FIG. 1 as asingle entity within AFSS 12, it is understood that chargeback rulesdatabase 62 may, in some embodiments, be distributed across multipledatabases and/or multiple physical/hardware memories, and/or may bewholly or partially external to (e.g., remote from) AFSS 12.

Image analysis unit 52 may generally analyze image data corresponding tophysical documents to identify fraudulent (e.g., counterfeit and/orforged) documents, and/or to flag potentially fraudulent documents forfurther (e.g., manual) review. For example, image analysis unit 52 mayanalyze information obtained from merchant computing systems 22 todetermine whether there is a relatively high probability that documentspresented to the merchants (e.g., personal checks, identification cards,etc.) are fraudulent. Image analysis unit 52 may be configured toanalyze only a single type of document, or multiple types of documents.The operation of image analysis unit 52, including the imagecharacteristics analyzed and the ways in which the characteristics maybe used to arrive at a result (e.g., flagging a document as potentiallyfraudulent), may be dictated by the rules stored in ML rules database58. Examples of the operation of image analysis unit 52 are providedbelow in connection with FIGS. 4F and 10, according to variousembodiments.

Classification unit 54 may generally analyze broad categories of datafrom various sources (e.g., account records database 30, cardholdercomputing devices 20, merchant computing systems 22, and/or othersources 24) to categorize/classify types of suspected fraudulentfinancial activity. Classification unit 54 may classify fraudulentactivity only within a particular subset of fraudulent financialactivity (e.g., classifying debit and/or credit card transactions asinvolving a potential case of counterfeiting, skimming, lost/stolen carduse, chargeback fraud, etc.), or may classify fraudulent financialactivity across a broader spectrum (e.g., including types of identitytheft not necessarily tied to a single financial transaction, such asapplication fraud). In some embodiments, classification unit 54classifies suspected fraudulent activity in connection with a particularaccount or transaction in response to being notified of suspect activity(e.g., notified by another component of fraud detection/classificationunit 36, or by a manual user input, etc.). In other embodiments,classification unit 54 itself (or another component of frauddetection/classification unit 36) identifies suspect activity beforeclassification unit 54 classifies that activity. Examples of theoperation of classification unit 54 are provided below in connectionwith FIGS. 4C and 11, according to various embodiments.

Notification unit 56 may generally provide alerts, confirmations, and/orother notifications to various individuals (e.g., customers, bankemployees associated with FAMS 14, third party employees associated withAFSS 12, etc.). For example, notification unit 56 may generate anotification message stating that a fraud alert associated with aparticular transaction is a false positive, and cause network interface32 to send the message to a computer terminal or to FAMS 14 for displayto a system user. As another example, notification unit 56 may causenetwork interface 32 to send other flagged transactions and/or documents(e.g., chargeback candidates identified by chargeback analysis unit 50,documents that image analysis unit 52 has identified as potentiallyfraudulent, etc.) to a computer terminal or FAMS 14 for display to asystem user. As yet another example, notification unit 56 may causenetwork interface 32 to send queries generated by dispute resolutionunit 46 to various ones of cardholder computing devices 20 for displayto cardholders.

The operation of various components of the environment 10 shown in FIG.1, according to different embodiments and/or scenarios, will bedescribed further below in connection with the remaining figures.

III. Exemplary Process Flows for Machine Learning of Fraud Detectionand/or Classification Rules

As discussed above, ML rule generator 40 may generate and/or updaterules that are used for one or more of a variety of different purposesrelating to fraud detection and/or classification. FIG. 2 depicts onegeneralized, example process flow 80 for machine learning that may beimplemented by ML rule generator 40, and possibly one or more othercomponents of fraud detection/classification unit 36.

In the process flow 80, multi-account data 82 may represent dataassociated with multiple financial accounts, each with one or moreaccount holders. The financial accounts may be existing or potentialaccounts, and the account holders may include holders of accounts and/orpotential holders of potential accounts. For example, the multi-accountdata 82 may include existing and/or applied-for credit card accounts,debit card accounts, savings accounts, checking accounts, investmentaccounts, loan accounts, etc.

Depending upon the embodiment, the multi-account data 82 may include oneor more different types of information obtained (e.g., by external datacollection unit 42 of FIG. 1) from one or more of FAMS 14, cardholdercomputing devices 20, merchant computing systems 22, and/or othersources 24. For example, the multi-account data 82 may includetransaction data (e.g., transaction dates, amounts, locations, etc.)from account records database 30 of FAMS 14, data indicative of InternetProtocol (IP) addresses of cardholder computing devices 20 and/ordevices in merchant computing systems 22, Internet browsing and/orsearch history data from cardholder computing devices 20 (or from an ISPcomputer system included in other sources 24, etc.), vehicle telematicsdata from telematics systems of cardholder vehicles, home occupancyand/or usage data (e.g., smart appliance data) from smart home systemsof cardholders, autonomous or smart vehicle data, vehicle navigationsystem data, mobile device data, mobile device and/or vehicle GPS data,and/or one or more other types of data. In some embodiments, themulti-account data 82 only includes data that account holders orpotential account holders have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forfraud protection services). In certain other embodiments, however,express consent is only needed for certain types of information, such asbrowsing history information, vehicle telematics data, etc.

The multi-account data 82 may be associated with multiple frauddetermination labels. The labels may simply reflect whether or not fraudexisted (e.g., “fraud” or “no fraud”), or may also indicate a type orclass of fraud (e.g., “counterfeiting,” “lost or stolen card use,”etc.), for example. In one embodiment, each of a number of data sets inthe multi-account data 82 is associated with such a label, and includesdata relating to a particular financial transaction, financial account,loan application, etc., for which the fraud determination was made(e.g., after a manual and/or automated fraud investigation). The labelsmay include final fraud determinations that were made via earlieriterations of the process flow 80, and/or external to the process flow80.

To provide a more detailed example, a first data set associated with a“card present” credit card transaction may include data describing thattransaction (e.g., from account records database 30) and data indicativeof the cardholder's online browsing activity (e.g., from one ofcardholder computing devices 20) for the 15 days immediately precedingthe transaction, and be labeled “confirmed fraud.” A second data set,associated with another “card present” transaction (for the sameaccount, or for a different account), may include the same general typesof data but be labeled “no fraud,” and so on. In some embodiments and/orscenarios, the same data may appear in, or be used by, two or more ofthe data sets. If the two “card present” transactions described aboveare both associated with the same account, for example, and if thesecond transaction occurred less than 15 days after the firsttransaction, some of the same online activity data may be shared by thefirst and second data sets.

At a process stage 84, the multi-account data 82 may be analyzed togenerate fraud detection and/or classification rules (e.g., to be storedin ML rules database 58). Any suitable type of supervised machinelearning program/technique(s) may be used, such as SVMs, neuralnetworks, logistic regression, etc. Generally, process stage 84 mayserve to identify which type(s) of data is/are probative of whetherfraud has occurred (and/or the type/category of fraud that may haveoccurred), and to determine the data values and/or combinations that areprobative of whether fraud has occurred (and/or the type/category offraud that may have occurred). By analyzing many (e.g., thousands) ofpositively and negatively labeled data sets in the multi-account data82, for example, process stage 84 may learn that certain spendingpatterns within a threshold time of a transaction tend to indicate thatthe cardholder made the transaction (e.g., thereby indicating that fraudhas not occurred, or that a fraud report is itself fraudulent ormistaken, etc.), that certain types of online searches by a cardholder(e.g., including a descriptor of a product purchased in the transaction,or a name of the merchant, etc.) tend to indicate that the cardholdermade the transaction, that the cardholder's distance from the site of a“card present” transaction (e.g., as determined from GPS informationprovided by the cardholder's smartphone, wearable electronics, orvehicle) relates to the probability of fraudulent activity according toa particular equation, and so on. Other specific examples of such rules,and how those rules may be generated, are discussed below in connectionwith FIGS. 3A-3F and 4A-4F, according to various embodiments.

At process stage 86, the rules generated or updated at process stage 84may be applied to first account data 90 associated with a particularaccount and customer(s) (e.g., a customer associated with a particularone of computing devices 20). The types of data included in firstaccount data 90 may depend upon which types of data were determined, byprocess stage 84, to be relevant to a fraud determination. For example,if the rules give weight to the amount and date of a financialtransaction when determining whether the transaction is fraudulent, andalso give weight to whether the account holder visits a particular typeof website, then the first account data 90 may include the amount anddate of one or more transactions, as well as data indicative of visitedweb sites (e.g., Uniform Resource Locators (URLs) and/or content ofvisited websites, etc.). The first account data 90 may includeinformation obtained (e.g., by external data collection unit 42) fromone or more of FAMS 14, one of cardholder computing devices 20associated with the customer holding the first account, one or more ofmerchant computing systems 22, and/or one or more of other sources 24,for example.

Process stage 86 may output various different types of information,depending upon the embodiment and/or scenario. For example, dependingupon the content of first account data 90 and the rules generated orupdated at process stage 84, process stage 86 may generate dataindicating that a particular financial transaction associated with firstaccount data 90 is, or is not, fraudulent or potentially fraudulent.Alternatively, or additionally, process stage 86 may generate dataindicating a particular classification for fraudulent or suspectedfraudulent activity (e.g., a fraudulent transaction) associated withfirst account data 90.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) may be performedat an additional stage, shown in dashed lines in FIG. 2 as process stage92. The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether fraud occurred, and/oron the type of fraud that occurred) at process stage 94. In otherembodiments, process stage 92 is omitted from process flow 80, andprocess stage 94 merely represents the output of process stage 86. Thefinal determination made at process stage 94, along with the firstaccount data 90 used to make that determination, may be fed back intoprocess stage 84 to provide additional labeled data for purposes ofupdating the rules.

In some embodiments, the process flow 80 includes more, fewer and/ordifferent stages, such as any of those discussed elsewhere herein (e.g.,in connection with FIGS. 3A-3F). In one alternative embodiment, processstages 84 and 86 may be combined. For example, the multi-account data 82may be unlabeled rather than labeled (or the labels may be ignored), andthe combined process stage 84, 86 may use unsupervised learningtechniques (e.g., clustering techniques) to classify anomalous/outlierfinancial transactions, accounts, applications, etc., as “suspect” andneeding further analysis.

More specific, machine learning-based process flows generallycorresponding to process flow 80 of FIG. 2 will now be described withreference to FIGS. 3A-3F. It is noted, however, that other process flowsare also within the scope of the invention described herein. Moreover,while FIGS. 3A-3F generally correspond to embodiments in whichsupervised machine learning techniques are used, other embodiments mayinstead use unsupervised machine learning techniques, as noted above. Invarious different embodiments, fraud detection/classification unit 36may be configured to implement only one of the process flows of FIGS.3A-3F, or may be configured to implement two or more (e.g., all) of theprocess flows shown in FIGS. 3A-3F.

A. Exemplary Process Flow for Machine Learning of Fraud Detection RulesUsing Online Activity Data

Referring first to FIG. 3A, an exemplary process flow 100 may generallybe used to detect fraud using customer online activity data. In theprocess flow 100, multi-customer online activity data 102 may representdata associated with the online activities of a number (e.g., thousands)of customers (e.g., credit or debit cardholders, checking or savingaccount holders, etc.). The multi-customer online activity data 102 mayinclude data indicating actions that the customers took, and/or websites visited by the customers, while the customers were connected tothe Internet via web browsers (e.g., executing on respective ones ofcardholder computing devices 20). For example, the multi-customer onlineactivity data 102 may include URLs of, and/or content (e.g., text)within, web sites visited by customers, search terms entered bycustomers using search engine tools, search results presented tocustomers by search engine tools, indications of interactive controls(e.g., virtual buttons) selected by customers on various web pages, andso on.

The multi-customer online activity data 102 may include data obtained(e.g., by external data collection unit 42 of FIG. 1) from cardholdercomputing devices 20, from one or more ISPs of other sources 24, and/orfrom a third party aggregator of such information, for example. In someembodiments, the multi-customer online activity data 102 may onlyinclude data that customers have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forfraud protection services or other benefits, such as discounts).

As described above in connection with multi-account data 82 of processflow 80, the multi-customer online account data 102 may be associatedwith multiple fraud determination labels. In some embodiments, eachlabel may be associated with a data set that includes not only thecorresponding portion of multi-customer online activity data 102, butalso one or more other types of data, such as transaction data (e.g.,transaction dates, amounts, locations, etc.) for each customer fromaccount records database 30 of FAMS 14, data indicative of IP addressesof cardholder computing devices 20 and/or devices in merchant computingsystems 22, Internet browsing and/or search history data from cardholdercomputing devices 20 (or from an ISP computer system included in othersources 24, etc.), vehicle telematics data from telematics systems ofother sources 24, home occupancy and/or usage data (e.g., smartappliance data) from smart home systems of other sources 24, and so on.The labels may include final fraud determinations that were made viaearlier iterations of the process flow 100, and/or external to theprocess flow 100. Multi-customer online account data 102 may includemany (e.g., thousands) of positively and negatively labeled data sets.

At a process stage 104, the multi-customer online activity data 102 maybe analyzed to generate fraud detection rules (e.g., to be stored in MLrules database 58). As described above in connection with process stage84 of process flow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 104 may serveto identify which type(s) of online activity data is/are probative ofwhether fraud has occurred, and to determine the data values and/orcombinations that are probative of whether fraud has occurred. While notshown in FIG. 3A, the fraud detection rules may not only detect fraud,but also classify fraud (e.g., as described below in connection withFIG. 3C), in some embodiments.

At process stage 106, the rules generated or updated at process stage104 may be applied to first customer online activity data 110. The firstcustomer online activity data 110 may be associated with a particularcustomer, such as a customer associated with a particular one ofcomputing devices 20, for example. The types of data included in firstcustomer online activity data 110 may depend upon which types of onlineactivity data were determined, by process stage 104, to be relevant to afraud determination. For example, the first customer online activitydata 110 may include information obtained (e.g., by external datacollection unit 42) from one of cardholder computing devices 20 (i.e.,the device associated with the first customer), and/or from an ISP ofother sources 24. Some specific examples of rules that may be generatedby process stage 104, and applied at process stage 106, are describedbelow in connection with FIG. 4A.

Process stage 106 may output various different types of information,depending upon the embodiment and/or scenario. For example, dependingupon the content of first customer online activity data 110 and therules, process stage 106 may generate data indicating that a particularfinancial transaction associated with the first customer is, or is not,fraudulent or potentially fraudulent. Alternatively, or additionally,process stage 106 may generate data indicating a particularclassification of fraudulent or potentially fraudulent activityassociated with first customer online activity data 110.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) is performed at anadditional stage, shown in dashed lines in FIG. 3A as process stage 112.The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether fraud occurred, and/oron the type of fraud that occurred) at process stage 114. In otherembodiments, process stage 112 is omitted from process flow 100, andprocess stage 114 merely represents the output of process stage 106.

The final determination made at process stage 114, along with the firstcustomer online activity data 110 (and any other data) used to make thatdetermination, may be fed back into process stage 104 to provideadditional labeled data for purposes of updating the rules. In someembodiments, a preliminary fraud determination made at process stage 106is also fed back into process stage 104, to allow the machine learningprogram to determine and improve upon past performance/accuracy.

B. Exemplary Process Flow for Machine Learning of Chargeback CandidateDetection Rules

Referring next to FIG. 3B, an exemplary process flow 120 may generallybe used to identify the financial transactions for which chargebacks(e.g., post-transaction payments from merchants, or acquiring/merchantbanks, back to the issuer to return proceeds from transactions) areappropriate. In the process flow 120, multi-account transaction data 122may represent data associated with the financial transactions involvingthe accounts of a number (e.g., thousands) of credit or debitcardholders. The multi-account transaction data 122 may includeinformation such as transaction dates, transaction amounts, merchantnames (and/or aliases) associated with the transaction, informationrelating to how the card information was collected by the merchant(e.g., by swiping, an EMV chip reader, manual entry of the card number,etc.), geographic locations of “card present” transactions, and so on.The multi-account transaction data 122 may include data obtained (e.g.,by external data collection unit 42 of FIG. 1) from merchant computingsystems 22 and/or from acquiring/merchant banks associated with thosemerchants, for example.

Similar to the labels described above in connection with multi-accountdata 82 of process flow 80, the multi-account transaction data 122 maybe associated with multiple chargeback outcome labels. For example, eachlabel may be associated with a data set that includes the correspondingportion of multi-account transaction data 122. The outcome labels mayinclude final chargeback determinations that were made (in connectionwith the transactions represented in multi-account transaction data 122)via earlier iterations of the process flow 120, and/or external to theprocess flow 120. Multi-account transaction data 122 may include many(e.g., thousands) of positively and negatively labeled data sets.

At a process stage 124, the multi-account transaction data 122 may beanalyzed to generate chargeback candidate detection rules (e.g., to bestored in ML rules database 58). As described above in connection withprocess stage 84 of process flow 80, any suitable type of supervisedmachine learning program/technique(s) may be used. Generally, processstage 124 may serve to identify which type(s) of transaction data is/areprobative of whether, under the full chargeback rules of the cardnetwork entity, a chargeback is appropriate for a given transaction.Process stage 124 may also determine the transaction data values and/orcombinations that are probative of whether a chargeback is appropriatefor the transaction.

At a process stage 126, the rules generated or updated at process stage124 may be applied to first account transaction data 130 to determinewhether a transaction associated with the first account is a “good”chargeback candidate. Put differently, process stage 126 may, instead ofapplying the full chargeback rules of the card network entity (which maybe quite lengthy and complex) to the facts surrounding the transaction,use various factors and algorithms developed at process stage 124 todetermine whether there exists a relatively high probability that achargeback would be appropriate for the transaction if the fullchargeback rules were applied. The process stage 126 may calculate apercentage probability that the transaction is one in which a chargebackis appropriate, for example.

The first account transaction data 130 may be associated with theaccount of a particular cardholder or cardholders, such as a cardholderassociated with a particular one of cardholder computing devices 20, forexample. The types of data included in first account transaction data130 may depend upon which types of transaction-related data weredetermined, by process stage 124, to be relevant to a chargebackcandidate determination. For example, the first account transaction data130 may include information obtained (e.g., by external data collectionunit 42) from one of merchant computing systems 22 (e.g., the computingsystem of the merchant involved in the transaction being analyzed)and/or from an acquiring/merchant bank associated with that merchant.The first account transaction data 130 may also include informationabout one or more other transactions associated with the first account(e.g., data pertaining to other transactions occurring shortly beforeand/or after the transaction at issue). Some specific examples of rulesthat may be generated by process stage 124, and applied at process stage126, are described below in connection with FIG. 4B.

Process stage 126 may output information indicating whether theparticular transaction represented by first account transaction data 130is a “good” candidate for chargeback detection. For example, processstage 126 may output a percentage probability, calculated according tothe rules generated or updated at process stage 124, that thetransaction is one in which a chargeback is appropriate. As anotherexample, process stage 126 may output a binary indicator of whether thetransaction is, or is not, a strong/likely chargeback candidate (e.g.,by comparing the percentage probability to a threshold probability).

If the transaction is identified as a chargeback candidate at processstage 126, the full chargeback rules of the card network entity may beapplied at a process stage 132. Process stage 132 may include manualapplication of the full chargeback rules, and/or automated applicationof the full chargeback rules, in various different embodiments. Basedupon the analysis at process stage 132, a final chargeback determinationmay be made at a process stage 134. The final determination made atprocess stage 134, along with the first account transaction data 130(and any other data) used to make that determination, may be fed backinto process stage 124 to provide additional labeled data for purposesof updating the rules. In some embodiments, the indication of whetherthe transaction is a good chargeback candidate generated at processstage 126 may also be fed back into process stage 124, to allow themachine learning program to determine and improve upon pastperformance/accuracy.

C. Exemplary Process Flow for Machine Learning of Fraud ClassificationRules

Referring now to FIG. 3C, an exemplary process flow 140 may generally beused to classify instances of suspected or potential fraud. For example,the process flow 140 may represent ongoing, real-time or batchprocessing of a large amount of data associated with a large number ofpotential and/or existing financial accounts (e.g., all accountsassociated with a particular bank, or all accounts opting in to a fraudprotection program, etc.). In this manner, the process flow 140 may beused to initially flag situations for closer investigation, and provideone or more classifications of the type(s) of fraud potentially at issuein order to narrow or otherwise facilitate the investigation. In otherembodiments, the process flow 140 may be used to provide a narrowerclassification (e.g., “skimming”) when a broader class of fraud (e.g.,credit card fraud) is already suspected.

In the process flow 140, multi-account data 142 may represent dataassociated with financial accounts of a number (e.g., thousands) ofaccount holders. The financial accounts may be existing or potentialaccounts, and the account holders may include holders of accounts and/orpotential holders of potential accounts. For example, the multi-accountdata 142 may include existing and/or applied-for credit card accounts,debit card accounts, savings accounts, checking accounts, investmentaccounts, loan accounts, etc.

Depending upon the embodiment, the multi-account data 142 may includeone or more different types of information obtained (e.g., by externaldata collection unit 42 of FIG. 1) from one or more of FAMS 14,cardholder computing devices 20, merchant computing systems 22, and/orother sources 24. For example, the multi-account data 142 may includetransaction data (e.g., transaction dates, amounts, locations, etc.)from account records database 30 of FAMS 14, data indicative of IPaddresses of cardholder computing devices 20 and/or devices in merchantcomputing systems 22, Internet browsing and/or search history data fromcardholder computing devices 20 (or from an ISP computer system includedin other sources 24, etc.), vehicle telematics data from telematicssystems of cardholder vehicles, home occupancy and/or usage data (e.g.,smart appliance data) from smart home systems of cardholders, and/or oneor more other types of data. Some or all data within multi-account data142 may be information that account holders or potential account holdershave expressly consented to share with an entity associated with FAMS 14and/or AFSS 12 (e.g., in exchange for fraud protection services).

The multi-account data 142 may be associated with multiple frauddetermination labels, each indicating a type or class of fraud (e.g.,“counterfeiting,” “lost or stolen card use,” “skimming,” “chargebackfraud,” “application fraud,” etc.), or indicating a lack of fraud, forexample. In one embodiment, each of a number of data sets in themulti-account data 142 is associated with at least one suchclassification/label, and includes data relating to a particularfinancial transaction, financial account, loan application, etc., forwhich the fraud classification or classifications was/were made (e.g.,after a previous iteration of process flow 140, or after another manualand/or automated fraud investigation). Multi-account data 142 mayinclude many (e.g., thousands) of data sets labeled with various knownfraud classifications.

At a process stage 144, the multi-account data 142 may be analyzed togenerate fraud classification rules (e.g., to be stored in ML rulesdatabase 58). As described above in connection with process stage 84 ofprocess flow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 144 may serveto identify which type(s) of transaction data is/are probative of theparticular type of fraud (if any) that has occurred. Process stage 144may also determine the data values and/or combinations that areprobative of the particular type of fraud (if any) that has occurred.

At a process stage 146, the rules generated or updated at process stage144 may be applied to first account data 150. The first account data 150may be associated with a particular account and a particular customer(e.g., a cardholder associated with a particular one of computingdevices 20). The types of data included in first account data 150 maydepend upon which types of data were determined, by process stage 144,to be relevant to fraud classification. For example, the first accountdata 150 may include information obtained (e.g., by external datacollection unit 42) from one or more of FAMS 14, one of cardholdercomputing devices 20 (i.e., the device associated with the customerholding or applying for the first account), one or more of merchantcomputing systems 22, and/or one or more of other sources 24. Somespecific examples of rules that may be generated by process stage 144,and applied at process stage 146, are described below in connection withFIG. 4C.

Process stage 146 may output data (e.g., a message or code) that is usedto classify suspected fraudulent activity (in connection with theaccount associated with first account data 150) at a process stage 152.For example, process stage 152 may assign a classification of“counterfeiting” if process stage 146 determined that the first accountdata 150 indicated a number of circumstances that, according to therules generated at process stage 144, are known to be correlated withcounterfeiting activity (e.g., two “card present” transactions occurringin different states within the same one-hour time period, etc.). In someembodiments and/or scenarios, two or more classifications mayconcurrently be assigned to first account data 150. For example, processstage 146 may determine a set of probabilities for a set of two or morepotential types of fraud, and process stage 152 may assign eachclassification, with each respective probability, to first account data150. Moreover, in some embodiments and scenarios, process stage 152 mayassign a classification that corresponds to an absence of any suspectedfraud (e.g., “no fraud”).

At a process stage 154, if process stage 152 assigned a classificationother than one indicating the absence of suspected fraud, the firstaccount data 150, and/or other information associated with the accountand the suspected class of fraud, may be analyzed in depth to make afinal fraud determination at a process stage 156. Generally, the fraudclassification may be used to facilitate the analysis at process stage154, with process stage 154 including manual and/or automated frauddetection techniques. For example, personnel associated with AFSS 12 mayuse the fraud classification(s) to inform their strategy and/or focuswith respect to conducting an in-depth fraud investigation.

The additional analysis at process stage 154 may then result in a finalfraud determination at process stage 156. The final determination mayindicate both whether fraud occurred and, if so, the class(es)/type(s)of fraud that occurred. The final determination made at process stage156, and information used to make that determination (e.g., the firstaccount data 150 and potentially other data), may be fed back intoprocess stage 144 to provide additional labeled data for purposes ofupdating the rules. In some embodiments, the (preliminary) fraudclassification made at process stage 152 may also be fed back intoprocess stage 144 to help the machine learning program identifyinstances in which the preliminary classifications at process stage 152were incorrect. Process stage 144 may then update the fraudclassification rules in ways that seek to prevent or reduce suchinstances in the future.

D. Exemplary Process Flow for Machine Learning of Application FraudDetection Rules

Referring now to FIG. 3D, an exemplary process flow 160 may generally beused to detect application fraud. “Application fraud” may generallyrefer to fraud in connection with the application for any type offinancial account, loan and/or line of credit (e.g., mortgage loan,vehicle loan, small business loan, payday loan, home equity line ofcredit, credit card account, debit card account, checking account,savings account, investment account, etc.). In some embodiments and/orscenarios, however, the application may be for non-financial purposes,such as an application for membership in a particular group orinstitution, for example.

In the process flow 160, multi-applicant search history data 162 mayrepresent data associated with the Internet search history of a number(e.g., thousands) of applicants. The multi-applicant search history data162 may include search terms entered by the applicants using onlinesearch engine tools, for example, and/or the results of such searches(e.g., URLs, titles and/or contents of search results), for example.

The multi-applicant search history data 162 may include data obtained(e.g., by external data collection unit 42 of FIG. 1) from cardholdercomputing devices 20, from one or more ISPs of other sources 24, and/orfrom a third party aggregator of such information, for example. In someembodiments, the multi-applicant search history data 162 only includesdata that the applicants have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forconsideration of their applications).

As described above in connection with multi-account data 82 of processflow 80, the multi-applicant search history data 162 may be associatedwith multiple fraud determination labels. In some embodiments, eachlabel may be associated with a data set that corresponds to anapplication submitted by a particular applicant, where the data setincludes the corresponding portion of multi-applicant search historydata 162 (e.g., the search terms and/or results associated with theparticular application). The labels may include final frauddeterminations that were made via earlier iterations of the process flow160, and/or external to the process flow 160. Multi-applicant searchhistory data 162 may include many (e.g., thousands) of positively andnegatively labeled data sets.

At a process stage 164, the multi-applicant search history data 162 maybe analyzed to generate application fraud detection rules (e.g., to bestored in ML rules database 58). As described above in connection withprocess stage 84 of process flow 80, any suitable type of supervisedmachine learning program/technique(s) may be used. Generally, processstage 164 may serve to identify which type(s) of Internet search-relateddata is/are probative of whether application fraud has occurred, and todetermine the data values and/or combinations that are probative ofwhether application fraud has occurred.

At process stage 166, the rules generated or updated at process stage164 may be applied to first applicant search history data 170. The firstapplicant search history data 170 may be associated with a particularapplication and a particular applicant (e.g., a person associated with aparticular one of computing devices 20), for example. The types of dataincluded in first applicant search history data 170 may depend uponwhich types of Internet search-related data were determined, by processstage 164, to be relevant to a fraud determination. The first applicantsearch history data 170 may include information obtained (e.g., byexternal data collection unit 42) from one of computing devices 20(i.e., the device associated with the first applicant), and/or from anISP of other sources 24, for example. Some specific examples of rulesthat may be generated by process stage 164, and applied at process stage166, are described below in connection with FIG. 4D.

Process stage 166 may output information indicating whether fraud issuspected in connection with the application corresponding to firstapplicant search history data 170. For example, process stage 166 mayoutput a percentage probability, calculated according to the rulesgenerated or updated at process stage 164, that the application wasfraudulently made (e.g., by someone other than the purported applicantor an authorized representative thereof). As another example, processstage 166 may output a binary indicator of whether the applicationlikely was, or likely was not, fraudulently made (e.g., by comparing apercentage probability to a threshold probability).

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) is performed at anadditional stage, shown in dashed lines in FIG. 3D as process stage 172.The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether application fraudoccurred) at process stage 174. In other embodiments, process stage 172is omitted from process flow 160, and process stage 174 merelyrepresents the output of process stage 166. The final determination madeat process stage 174, along with the first applicant search history data170 (and any other data) used to make that determination, may be fedback into process stage 164 to provide additional labeled data forpurposes of updating the rules. In some embodiments, a preliminary frauddetermination made at process stage 166 is also fed back into processstage 164, to allow the machine learning program to determine andimprove upon past performance/accuracy.

E. Exemplary Process Flow for Machine Learning of Fraud DisputeResolution Rules

Referring now to FIG. 3E, an exemplary process flow 180 may generally beused to facilitate the resolution of fraud disputes (or potentialdisputes) with customers/account holders. For example, the process flow180 may be used to determine whether a reportedly unauthorized orfraudulent transaction (e.g., one that the account holder reported assuch when looking at his or her account statement) was indeedunauthorized or fraudulent. In some embodiments, the process flow 180may also, or instead, be used to determine whether an “unrecognized”transaction (i.e., one that the account holder does not recall, but doesnot necessarily report as fraudulent) was unauthorized or fraudulent.

In the process flow 180, multi-account data 182 may represent dataassociated with financial accounts of a number (e.g., thousands) ofaccount holders. For example, the multi-account data 182 may includedata associated with financial transactions relating to credit cardaccounts, debit card accounts, savings accounts, checking accounts, etc.For ease of explanation, FIG. 3E will be described with reference to anembodiment in which the accounts are credit card accounts.

In one embodiment, the multi-account data 182 may include transactiondata (e.g., transaction dates, amounts, locations, etc.) obtained fromFAMS 14 (e.g., by external data collection unit 42 of FIG. 1). In someembodiments, however, the multi-account data 182 also includesinformation obtained from cardholder computing devices 20, merchantcomputing systems 22, and/or other sources 24. For example, themulti-account data 182 may include, in addition to transaction data fromaccount records database 30 of FAMS 14, data indicative of IP addressesof cardholder computing devices 20 and/or devices in merchant computingsystems 22, Internet browsing and/or search history data from cardholdercomputing devices 20 (or from an ISP computer system included in othersources 24, etc.), vehicle telematics data from telematics systems ofcardholder vehicles, home occupancy and/or usage data (e.g., smartappliance data) from smart home systems of cardholders, autonomousvehicle data, smart vehicle data, mobile device data, vehicle or mobiledevice GPS data, and/or one or more other types of data. Some or alldata within multi-account data 182 may be information that accountholders or potential account holders have expressly consented to sharewith an entity associated with FAMS 14 and/or AFSS 12 (e.g., in exchangefor fraud protection services).

As described above in connection with multi-account data 82 of processflow 80, the multi-account data 182 may be associated with multiplefraud determination labels (e.g., “fraud” and “no fraud,” and/or morecomplex labels that indicate type/class, such as “lost/stolen card use,”etc.). In some embodiments, each label may be associated with a data setthat includes the corresponding portion of multi-account data 182. Thelabels may include final fraud determinations that were made via earlieriterations of the process flow 180, and/or external to the process flow180. Multi-account data 182 may include many (e.g., thousands) ofpositively and negatively labeled data sets.

At a process stage 184, the multi-account data 182 may be analyzed togenerate query generation rules (e.g., to be stored in ML rules database58). As described above in connection with process stage 84 of processflow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 184 may serveto identify which types of information are probative of whether fraudhas occurred, and to craft rules that formulate queries to ascertainsuch information based upon account data.

For example, process stage 184 may determine that, for a suspect “cardpresent” transaction, a verified, non-fraudulent “card present”transaction within 10 miles and 3 hours of the suspect transaction isprobative of whether the suspect transaction was fraudulent. Based uponthis finding, process stage 184 may also generate a rule specifying thata cardholder should be queried as to whether he/she can confirm makingeach “card present” transaction within 10 miles and 3 hours of thesuspect transaction. As another example, process stage 184 may determinethat a merchant using a billing alias different from its legal and/orcommonly-known name (e.g., by at least some threshold level ofsimilarity, as measured by number of similar characters, order ofcharacters, etc.) is probative of whether the cardholder authorized atransaction associated with that billing alias. Based upon this finding,process stage 184 may generate a rule specifying that a cardholdershould be queried as to whether he/she is aware of a billing alias usedfor a suspect transaction if that billing alias is sufficientlydifferent from the legal/common name of the merchant.

At process stage 186, the rules generated or updated at process stage184 may be applied to first account data 190. The first account data 190may be associated with a particular cardholder, such as a cardholderassociated with a particular one of cardholder computing devices 20, forexample. The types of data included in first account data 190 may dependupon which types of data were determined, by process stage 184, to berelevant to developing dispute resolution queries. Process stage 186 maygenerate a set of one or more queries in accordance with the rules andthe contents of first account data. Some specific examples of rules thatmay be generated by process stage 184 and applied at process stage 186,and the queries that may be generated as a result, are described belowin connection with FIG. 4E.

At a process stage 192, the generated queries may be sent to thecardholder in one or more of various ways, such as sending the queriesvia SMS text message and/or email, and/or via a web browser or dedicatedapplication executing on the one of cardholder computing devices 20 thatis associated with the cardholder, for example. At a process stage 194,responses to the queries are received from the cardholder (e.g., viainputs made by the cardholder via the web browser or application, or aresponsive SMS text message or email, etc.). In some embodiments, therules generated or updated at process stage 184 specify the manner inwhich follow-up queries should be generated based upon the responsesreceived at process stage 194, and process stages 192 and 194 may berepeated multiple times.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) that makes use ofthe received responses is performed at an additional stage, shown indashed lines in FIG. 3E as process stage 196. The additional analysismay then be used to make a final fraud determination (e.g., a finaldecision on whether fraud occurred, and/or on the type of fraud thatoccurred) at process stage 198. In other embodiments, process stage 196is omitted from process flow 180, and process stage 198 is based uponinformation from the cardholder. For example, the questions generated atprocess stage 192 may “jog” the cardholder's memory, and cause him orher to indicate that the transaction at issue was authorized. The finaldetermination made at process stage 198, along with the first accountdata 110 (and any other data used at process stage 196), the queriesgenerated at process stage 186 and/or the responses received at processstage 194, may be fed back into process stage 184 to provide additionallabeled data for purposes of updating the rules.

F. Exemplary Process Flow for Machine Learning of Document FraudDetection Rules

Referring now to FIG. 3F, an exemplary process flow 200 may generally beused to detect fraud relating to documents, such as counterfeit and/orforged documents. The process flow 200 may be used in connection withvarious kinds of documents, such as checks (e.g., personal checks,cashier's checks, etc.), money orders, treasury bills, identificationdocuments (e.g., social security cards, driver's licenses, passports,birth certificates, etc.), certification documents, and so on.

In the process flow 200, multi-document image data 202 may representdigital images of a number (e.g., thousands) of physical documents ofone or more types. The multi-document image data 202 may include imagesin one or more formats, such as raster formats (e.g., JPEG, TIFF, GIF,BMP, PNG, etc.) and/or vector formats (e.g., CGM, SVG, etc.), forexample. The multi-document image data 202 may include data obtained(e.g., by external data collection unit 42 of FIG. 1) from merchantcomputing systems 22 (e.g., point-of-sale devices with cameras fordocument identification) and/or from FAMS 14 (e.g., images of personalchecks), for example. In some embodiments, the multi-document image data202 may only include data representing images that customers (or otherindividuals associated with the documents) have expressly consented toshare (e.g., as a prerequisite to making a purchase, or in exchange forfraud protection services, etc.).

As described above in connection with multi-account data 82 of processflow 80, the multi-document image data 202 may be associated withmultiple fraud determination labels. In some embodiments, each label maybe associated with data representing a digital image of a particulardocument. The labels may include final fraud determinations (e.g.,“fraud” or “no fraud,” or more complex labels such as “forgery,”“counterfeit,” “forgery—signature,” “counterfeit—angular line offset(s)outside tolerance,” etc.) that were made via earlier iterations of theprocess flow 200, and/or external to the process flow 200.Multi-document image data 202 may include many (e.g., thousands) ofpositively and negatively labeled data sets.

At a process stage 204, the multi-document image data 202 may beanalyzed to generate document fraud detection rules (e.g., to be storedin ML rules database 58). As described above in connection with processstage 84 of process flow 80, any suitable type of supervised machinelearning program/technique(s) may be used. Generally, process stage 204may serve to identify which characteristics of a document are probativeof whether the document is counterfeit, and to determine the ranges,tolerances, etc., that are probative of whether the document iscounterfeit. In some embodiments, process stage 204 also, or instead,identifies which characteristics of information entered in documentfields are probative of whether the document was forged (e.g., draftedor populated by someone other than the person purported to have draftedor populated the document).

At process stage 206, the rules generated or updated at process stage204 may be applied to first document image data 210. The first documentimage data 210 may be digital image data corresponding to a particular,physical document. The first document image data 210 may includeinformation obtained (e.g., by external data collection unit 42) fromone of merchant computing systems 22 (e.g., for real-time verificationof an identification or other document presented during or prior to asale), or from FAMS 14 (e.g., for real-time or batch-processingverification of a personal check prior to clearing the check), forexample. Some specific examples of rules that may be generated byprocess stage 204, and applied at process stage 206, are described belowin connection with FIG. 4F.

Process stage 206 may output information indicating whether fraud issuspected in connection with the document corresponding to firstdocument image data 210. For example, process stage 206 may output twopercentage probabilities calculated according to the rules generated orupdated at process stage 204, with the first indicating the likelihoodthat the document is counterfeit and the second indicating thelikelihood that the document includes forged content. As anotherexample, process stage 206 may output binary indicators of whether thedocument likely is, or likely is not, counterfeit and/or includes forgedcontent (e.g., by comparing percentage probabilities to thresholdprobabilities).

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) may be performedat a process stage 212. The additional analysis may then be used to makea final fraud determination (e.g., a final decision on whether thedocument is fraudulent) at process stage 214. For example, the processstage 206 may act as a filter, and flag only those documents having arelatively high probability of being fraudulent. In this manner, aconsiderably smaller amount of human and/or processing resources may beconsumed at process stage 212.

The final determination made at process stage 214, along with the firstdocument image data 210 used to make that determination, may be fed backinto process stage 204 to provide additional labeled data for purposesof updating the rules. In some embodiments, a preliminary frauddetermination made at process stage 206 may also be fed back intoprocess stage 204, to allow the machine learning program to determineand improve upon past performance/accuracy.

IV. Exemplary Rules for Fraud Detection and/or Classification

FIGS. 4A-4F depict exemplary factors and algorithms that may be used inconnection with various fraud detection and/or classification rules,according to different embodiments. It is noted that the rule setscorresponding to FIGS. 4A-4F are purely for purposes of illustration andare not limiting. Particularly in embodiments where machine learning isutilized, for example, the algorithms and/or factors may be far morecomplex, and/or less intuitive, than some or all of the examples shownin FIGS. 4A-4F.

A. Exemplary Fraud Detection Rule Set Using Online Activity

Referring first to FIG. 4A, an exemplary rule set 220 (e.g., generatedat process stage 104 of FIG. 3A) may use various factors relating toonline activity of a cardholder to detect fraud in connection with aparticular credit or debit card transaction. The rule set 220 maycorrespond to a particular embodiment and scenario in which thetransaction at issue is a “card present” transaction, and in which therule set 220 seeks to determine whether the cardholder made or otherwiseauthorized the transaction. The rule set 220 may be incorporated into areview process that is generally applied to all transactions, a reviewprocess applied only to those transactions that were flagged by apreliminary fraud alert, or a review process applied only after acardholder reports the transaction as unauthorized, for example.

The factors considered under the rule set 220 may include a number ofinterest-based factors 222 and a number of location-based factors 224.The interest-based factors 222 may relate to the cardholder's interest(or non-interest) in a product or service purchased via the transaction,and/or the merchant providing the product or service, while thelocation-based factors 224 may relate to the cardholder's location orprobable location.

As seen in FIG. 4A, the interest-based factors 222 may include: (1)whether the cardholder searched online for the specific product orservice purchased via the transaction at issue (e.g., by determiningwhether search terms entered by the cardholder included the name of theproduct or service involved in the transaction, or included adescription of the product or service, etc.); (2) whether the cardholdervisited a website associated with the merchant (e.g., by comparing URLsof web sites visited by the cardholder to a known URL of the merchant'swebsite, or by searching the contents of websites visited by thecardholder for the merchant's name, etc.); (3) whether the cardholderendorsed the merchant, or the product or service provided by themerchant, via a social media account of the cardholder (e.g., bydetermining whether the cardholder “liked” the merchant, product orservice via his or her Facebook® account, etc.); (4) whether thecardholder visited a website associated with a competitor of themerchant (e.g., by comparing URLs of web sites visited by the cardholderto known URLs of known competitors' websites, or by searching thecontents of websites visited by the cardholder for the competitors'names, etc.); (5) whether the cardholder searched online for a differentproduct or service in the same price range as the transaction amount(e.g., by analyzing search terms and/or results, and/or by analyzingURLs or contents of websites visited by the cardholder and comparingprices of products/services, etc.); and/or (6) whether the cardholderentered search terms indicative of the cardholder's need for the productor service (e.g., by determining that the cardholder entered searchterms including “pipe leak” prior to the purchase of new plumbinghardware, or “computer repair” prior to the purchase of a new harddrive, etc.). In other embodiments, the interest-based factors 222 mayinclude more, fewer and/or different factors than those shown in FIG.4A.

As is also seen in FIG. 4A, the location-based factors 224 may include:(1) whether the cardholder “checked in” to a flight having a destinationnear the location where the transaction was initiated (e.g., bydetermining whether the cardholder checked in to a flight having adestination at the city in which the transaction occurred, or within athreshold number of miles of the city in which the transaction occurred,etc.); (2) whether the cardholder visited a website associated with aplace near (or in) which the transaction was initiated (e.g., bycomparing URLs of web sites visited by the cardholder to URLs ofwebsites known to be associated with particular areas, and/or bysearching the contents of websites visited by the cardholder forlocation or area names, etc.); and/or (3) whether the cardholderendorsed a place near (or in) which the transaction was initiated via asocial media account of the cardholder (e.g., by determining whether thecardholder “liked” the geographic area, attraction or other place viahis or her Facebook® account, etc.). In other embodiments, thelocation-based factors 224 may include more, fewer and/or differentfactors than those shown in FIG. 4A.

Generally, the data indicative of whether the circumstance correspondingto each of interest-based factors 222 and/or location-based factors 224is present/true for a particular cardholder may be included in the firstcustomer online activity data 110 described above in connection withFIG. 3A. For example, external data collection unit 42 of FIG. 1 mayobtain the search terms, URLs, user online selections, etc., needed todetermine whether the various factors exist, from the cardholder'scomputing device (e.g., one of cardholder computing devices 20) and/orfrom an ISP of other sources 24.

As is also seen in FIG. 4A, each of the interest-based factors 222 andlocation-based factors 224 may be associated with a particular score orweighting value. In the rule set 220 shown in FIG. 4A, a total score maybe calculated based upon which factors are, or are not, present (e.g.,add 94 points if it is determined that the cardholder searched for theparticular lawnmower model that was purchased, add another 80 points ifthe transaction was a “card present” transaction in the Chicago suburbof Joliet and the cardholder checked in to a flight to Chicago justprior to the transaction, etc.).

In some embodiments, certain factors may instead be associated withnegative scores (e.g., minus 80 if the cardholder checked in to a flightwith a destination at least 200 miles from the site of the transactionand within one day of the transaction, etc.). Moreover, certain factorsmay be associated with metrics or algorithms that determine how heavilythose factors are weighed. As indicated in FIG. 4A, for example, searchterms entered by the cardholder may be used to calculate a “need score”X (e.g., where X is based upon frequency of certain search terms beingused, the amount of time spent clicking through search results, themagnitude and/or urgency of a problem indicated by the search terms,etc.), with X then being used to calculate a score equal to 0.2X.

The rule set 220 may then output the total score (e.g., 94+80=+174), anormalized total score, an indication of whether the total scoreexceeded a threshold (e.g., a threshold of +100), a probabilitycalculated based upon the total score, and/or some other indicator ormeasure of the existence or likelihood of fraud. In the example shown inFIG. 4A, it can be seen that larger scores generally correspond to agreater probability that the transaction was made or authorized by thecardholder. If the transaction is being automatically reviewed (e.g., todetermine whether a fraud alert is appropriate, without any initialinput from the cardholder), this may mean that a lower score correspondsto a higher probability of fraud. Conversely, if the cardholder hadreported the transaction as being fraudulent, a higher score maycorrespond to a higher probability of fraud (i.e., fraud on the part ofthe cardholder).

In some embodiments, the rule set 220 may also include one or more othertypes of factors not necessarily based upon online activities of thecardholder (e.g., whether GPS of the cardholder's smartphone or vehicleindicates that he or she was in that area shortly before or after thetransaction, etc.), and/or may omit either interest-based factors 222 orlocation-based factors 224.

B. Exemplary Chargeback Candidate Detection Rule Set

Referring next to FIG. 4B, an exemplary rule set 230 (e.g., generated atprocess stage 124 of FIG. 3B) may use various factors relating to atransaction between a cardholder and a merchant to determine whether thetransaction should be flagged as a candidate for a chargeback (e.g., todetermine whether the transaction should be reviewed under a full set ofchargeback rules associated with the appropriate card network entity).The rule set 230 may correspond to a particular embodiment and scenarioin which the transaction at issue is a “card present” transaction.

As seen in FIG. 4B, the factors considered under the rule set 230 mayinclude: (1) whether an EMV chip card was not inserted in apoint-of-sale EMV chip reader device of the merchant; (2) whether anon-EMV card was not swiped in a point-of-sale device of the merchant;(3) whether the card is past its expiration date; (4) whether thetransaction is for the same amount and/or date as another transactioninvolving the same card and merchant (e.g., by analyzing othertransactions involving the same account and merchant within a particulartime span); and/or (2) whether the transaction is for greater than athreshold amount. For example, one of merchant computing systems 22 ofFIG. 1 (or an acquiring/merchant bank) may provide transaction detailsthat include the amounts, dates, etc., to FAMS 14 for storage in accountrecords database 30, and external data collection unit 42 may thenretrieve that information from account records database 30. Generally,the data indicative of whether the circumstance corresponding to each ofthe factors is present/true for a particular transaction may be includedin the first account transaction data 130 described above in connectionwith FIG. 3B. In other embodiments, the factors considered under ruleset 230 may include more, fewer and/or different factors than thoseshown in FIG. 4B. It is noted that, in some embodiments, one or morefactors may simply relate to the desirability (e.g., from a card issuerperspective) of further reviewing whether a chargeback is appropriate,without necessarily relating to the likelihood that a chargeback isappropriate.

As is also seen in FIG. 4B, each of the factors may be associated with aparticular score or weighting value. A total score may be calculatedbased upon which factors are, or are not, present (e.g., add 62 pointsif it is determined that the transaction has the same amount and date asanother transaction occurring close in time and involving the same cardand merchant). In some embodiments, certain factors may instead beassociated with negative scores, and/or certain factors may beassociated with metrics or algorithms that determine how heavily thosefactors are weighed.

The rule set 230 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the likelihood that a chargeback is appropriatefor the transaction. In the example shown in FIG. 4B, it can be seenthat larger scores generally correspond to a greater probability that achargeback is appropriate.

C. Exemplary Fraud Classification Rule Set

Referring now to FIG. 4C, an exemplary rule set 240 (e.g., generated atprocess stage 144 of FIG. 3C) may use a diverse array of factors toclassify the type(s) of fraudulent activity, if any, that is/aresuspected to be associated with an event or series of events. The ruleset 240 may correspond to a particular embodiment and scenario in whichthe event at issue is a financial transaction involving a debit orcredit card. In other embodiments and/or scenarios, however, the ruleset 240 may classify fraudulent activity with respect to specific othertypes of events (e.g., loan applications), or may detect a variety ofdifferent event types (e.g., various types of financial transactions,loan or credit applications, etc.) and broadly classify fraudulentactivity in connection with the detected event types (e.g., lost/stolencard use, application fraud, etc.).

In one embodiment, each potential classification (with the possibleexception of “no fraud”) may be associated with a number of factorsprobative of whether that type/class of fraud has occurred. As seen inFIG. 4C, for example, the rule set 240 may include counterfeit factors242 (e.g., factors indicating that a counterfeit card was used for thetransaction), account takeover factors 244 (e.g., factors indicatingthat the transaction resulted from an unauthorized person gaining onlineaccess to the credit or debit card account itself, via phishing, malwareor other means), chargeback fraud factors 246 (e.g., factors indicatingthat the cardholder made or otherwise authorized a purchase that thecardholder later contested) and skimming factors 248 (e.g., factorsindicating that the card information used for the transaction wasobtained via a skimming card reader device illegally installed in anATM, gas station pump or other location). In other embodiments, the ruleset 240 may also, or instead, include factors corresponding to one ormore other fraud classifications (e.g., forgery, lost/stolen card use,etc.).

As seen in FIG. 4C, the counterfeit factors 242 may include: (1) whetherthe suspect transaction and another, contemporaneous transaction (e.g.,occurring within one hour, etc.) in another state are both “cardpresent” transactions; and/or (2) if the suspect transaction is a “cardpresent” transaction, whether the card (if an EMV chip card) was notinserted in an EMV chip card reader. For example, one or more ofmerchant computing systems 22 of FIG. 1 (or one or moreacquiring/merchant banks) may provide transaction details that includewhether the transaction was “card present,” whether the card wasinserted in an EMV chip card reader, etc., to FAMS 14 for storage inaccount records database 30, and external data collection unit 42 maythen retrieve that information from account records database 30. Inother embodiments, the counterfeit factors 242 may include more, fewerand/or different factors than those shown in FIG. 4C.

The account takeover factors 244 may include: (1) whether the debit orcredit card account password was changed within the 10 days prior to thetransaction; and/or (2) whether the transaction was originated from anIP address not associated with the cardholder. For example, externaldata collection unit 42 may retrieve password change information fromaccount records database 30 of FIG. 1, which may log all password updateactivity, and/or may retrieve IP address information from one ofmerchant computing systems 22 (e.g., the computing system of themerchant involved in the transaction). In other embodiments, the accounttakeover factors 244 may include more, fewer and/or different factorsthan those shown in FIG. 4C.

The chargeback fraud factors 246 may include: (1) whether the cardholderhad searched online for the product or service purchased via thetransaction; and/or (2) whether the cardholder had visited a websiteassociated with the merchant involved in the transaction. For example,external data collection unit 42 of FIG. 1 may retrieve online searchinformation (e.g., search terms and/or results) and/or URLs from the oneof cardholder computing devices 20 that is associated with thecardholder, and/or from an ISP (of other sources 24) used by thecardholder. In other embodiments, the chargeback fraud factors 246 mayinclude more, fewer and/or different factors than those shown in FIG.4C.

The skimming factors 248 may include: (1) the number (X) of earliertransactions in which the card used for the transaction at issue wasused at an ATM machine or a gas station pump within the 10 days prior tothe transaction at issue; and/or (2) whether the transaction at issueoriginated from an IP address not associated with the cardholder. Forexample, external data collection unit 42 of FIG. 1 may retrievetransaction data indicating that certain past purchases were made usinggas station pump card readers, and/or indicating that the card was usedfor one or more ATM withdrawals, from account records database 30,and/or may retrieve the originating IP address from the one of merchantcomputing systems 22 associated with the merchant involved in thetransaction at issue. In other embodiments, the skimming factors 248 mayinclude more, fewer and/or different factors than those shown in FIG.4C.

Generally, the data indicative of whether the circumstance correspondingto each of counterfeit factors 242, account takeover factors 244,chargeback fraud factors 246 and/or skimming factors 248 is present/truefor a particular transaction may be included in the first account data150 described above in connection with FIG. 3C, for example.

As is also seen in FIG. 4C, each of the counterfeit factors 242, accounttakeover factors 244, chargeback fraud factors 246 and skimming factors248 may be associated with a particular score or weighting value. Thefactors for each classification (counterfeit, account takeover,chargeback fraud, skimming) may be used to calculate a total scorespecific to that classification. In the rule set 240 shown in FIG. 4C,for example, a counterfeit score may be calculated based upon which offactors 242 are, or are not, present, an account takeover score may becalculated based upon which of factors 244 are, or are not, present, andso on. In some embodiments, certain factors may instead be associatedwith negative scores, and/or certain factors (e.g., the first ofskimming factors 248 shown in FIG. 4C) may be associated with metrics oralgorithms that determine how heavily those factors are weighed.

For each classification/category, the rule set 240 may output the totalscore, a normalized total score, an indication of whether the totalscore exceeded a threshold, a probability calculated based upon thetotal score, and/or some other indicator or measure of the likelihoodthat fraud of that particular type/class occurred in connection with thetransaction. In the example shown in FIG. 4C, it can be seen that largerscores generally correspond to a greater probability that the respectiveclassification is accurate. Referring back to FIG. 3C, theclassification at process stage 152 may be the classification having thehighest score and/or probability under rule set 240, or may include thescore and/or probability for each classification, the top threeclassifications, etc.

D. Exemplary Application Fraud Detection Rule Set

Referring now to FIG. 4D, an exemplary rule set 260 may use onlinesearch information (e.g., search terms, search results, clicked/selectedsearch results, etc.) to detect whether an application was fraudulent(e.g., not populated and/or submitted by the purported applicant). Therule set 260 may have been generated at process stage 164 of FIG. 3D,for example. The rule set 260 may be incorporated into a review processthat is generally applied to all applications received by a particularentity or anti-fraud service, or a review process applied only to thoseapplications that were flagged by a preliminary fraud alert, forexample.

The factors considered under the rule set 260 may generally be probativeof whether the person that submitted the application (e.g., via a webbrowser, a dedicated application, as an email attachment, by snail mail,etc.) had performed one or more online searches indicating that he orshe was trying to learn more about the purported applicant in order topopulate particular fields of the application (e.g., a “home address”field, “employment history” fields, etc.). The “purported applicant” maybe a person whose name appears in a name and/or signature field of theapplication, for example.

As seen in FIG. 4D, the factors of exemplary rule set 260 may include:(1) whether the applicant used search terms that included the name ofthe purported applicant; (2) whether the search terms also included thewords “address” or “residence” (and possibly other synonyms ornear-synonyms); and/or (3) whether the search terms also included thewords “employer,” “job” and/or “career” (and possibly other synonyms ornear-synonyms). In other embodiments, the rule set 260 may include more,fewer and/or different factors than those shown in FIG. 4D. For example,the rule set 260 may include one or more factors relating to whichsearch results appeared and/or were selected (e.g., “clicked” on afterappearing on a user interface) by the applicant.

Generally, the data indicative of whether the circumstancescorresponding to the factors of rule set 260 are present/true for aparticular applicant may be included in the first applicant searchhistory data 170 described above in connection with FIG. 3D. Forexample, external data collection unit 42 of FIG. 1 may obtain thesearch terms, search results, search result user selections, etc.,needed to determine whether the various factors exist, from theapplicant's computing device (e.g., similar to one of cardholdercomputing devices 20) and/or from an ISP of other sources 24. Access tosuch information may be made a condition of having the application beconsidered, for example.

As is also seen in FIG. 4D, each of the factors of rule set 260 may beassociated with a particular score or weighting value. A total score maythen be calculated based upon which factors are, or are not, present. Insome embodiments, certain factors may instead be associated withnegative scores, and/or certain factors may be associated with metricsor algorithms that determine how heavily those factors are weighed.

The rule set 260 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the existence or likelihood of applicationfraud. In the example shown in FIG. 4D, it can be seen that largerscores may generally correspond to a greater probability that theapplication was not populated and/or submitted by the purportedapplicant.

E. Exemplary Fraud Dispute Resolution Rule Set

Referring now to FIG. 4E, a flow diagram illustrates at least a portionof a process flow 270 implementing an exemplary rule set for frauddispute, or potential fraud dispute, resolution (e.g., a rule setgenerated at process stage 184 of FIG. 3E). The process flow 270 may beused to help resolve a dispute over a contested transaction, or to helpa customer recall an unrecognized transaction, for example. FIG. 4Eillustrates a process flow, rather than just a set of factors, in orderto better illustrate an example process for generating queries basedupon the generated rules, according to one embodiment. The process flow270 may correspond to a particular embodiment and scenario in which thetransaction subject to dispute or potential dispute is a credit or debitcard transaction.

In the exemplary process flow 270, the rule set may specify that aprocess stage 272 determines whether the transaction was a “cardpresent” transaction. If not, the rule set may specify that the flowproceed directly to a process stage 280. If so, however, the rule setmay specify that the flow instead proceeds to a process stage 274.

The rule set may also specify that process stage 274 determines whetherat least one other transaction associated with the cardholder's accountoccurred within some threshold number of hours (X) of the transaction atissue. If not, the rule set may specify that the flow proceeds directlyto process stage 280. If so, however, the rule set may specify that theflow instead proceeds to a process stage 276.

Process stage 276 may generate one or more location-related queriesusing transaction data associated with the cardholder's account. Thequeries may ask, for example, whether the cardholder was in (or near)one or more particular geographic areas or locations at various times.If the transaction at issue occurred in San Francisco, for example, witha first other “card present” transaction occurring in Santa Rosa fourhours earlier and a second other “card present” transaction occurring inSan Jose two hours later, process stage 276 may generate one or morequeries asking whether the cardholder made or authorized the earlierand/or later transactions, and/or whether the cardholder traveled on aroute from Santa Rosa to San Jose that passed through San Francisco,etc.

In some embodiments, the location-related queries are generated basedupon data associated with events or circumstances other thantransactions. For example, if the transaction at issue occurred inSarasota, Fla., and the data considered under the rule set indicatesthat the cardholder checked in to a flight to Tampa, process stage 276may generate one or more queries asking whether the cardholder completedthe flight, where the cardholder went after landing in Tampa, etc.

The rule set may also specify that process stage 280 determines whetherthe transaction at issue is associated with a billing alias that isdissimilar to the name of the merchant involved in the transaction. Forexample, the computing system of the merchant (e.g., one of merchantcomputing systems 22 of FIG. 1) may have sent to FAMS 14 a transactionrecord that identified the merchant by the alias, and was presented tothe cardholder as an online or paper account statement. Thedetermination at process stage 280 may use the billing alias to identifya legal and/or common name of the merchant (e.g., using a relationaldatabase stored in AFSS 12 or FAMS 14), and determine that there is atleast some threshold level of dissimilarity (e.g., based upon differenceof characters, character ordering, etc.) between the billing alias andthe merchant name.

If the billing alias and merchant name are not sufficiently dissimilar,the rule set may specify that the flow proceeds directly to a processstage 284. If sufficiently dissimilar, however, the rule set may specifythat the flow instead proceeds to a process stage 282. Process stage 282may generate a query relating to the billing alias that was presented tothe cardholder. For example, the query may ask whether the cardholder isaware that the billing alias is used by that particular merchant. Insome embodiments, process stage 282 may instead generate a message thatsimply informs the cardholder that the billing alias corresponds to themerchant, without posing a question.

The rule set may specify that process stage 284 generates one or moredefault queries. For example, one default query may ask whether thecardholder lent his or her card to a friend or family member around thetime of the transaction. In some embodiments and/or scenarios, processstage 284 may be omitted from process flow 270. Generally, the queries(and possibly non-query messages) generated in process flow 270 mayserve to help the cardholder recall whether the transaction was made orauthorized, and/or process flow 270 may prompt the cardholder forresponses that are considered by others (e.g., personnel of an entityassociated with FAMS 14 of FIG. 1) to determine whether the transactionwas likely fraudulent.

Although not shown in FIG. 4E, in some embodiments process flow 270 mayinclude a number of iterative stages in which responses are receivedfrom the cardholder (e.g., from the respective one of cardholdercomputing devices 20 in FIG. 1) and used to generate additional, moredetailed questions for the cardholder. For example, if a first queryasks whether the cardholder recalls personally making another “cardpresent” transaction that occurred at a nearby time and place, and thecardholder responds “no,” a new query may be generated asking whetherthe cardholder recalls personally making the next closest transaction(in terms of time and/or location).

F. Exemplary Document Fraud Detection Rule Set

Referring next to FIG. 4F, an exemplary rule set 290 (e.g., generated atprocess stage 204 of FIG. 3F) may use various factors relating to animaged (e.g., photographed or scanned) physical document to determinewhether the document should be flagged as a candidate for a morein-depth (e.g., manual) analysis/review for fraud purposes. The rule set290 may correspond to a particular embodiment and scenario in which thedocument is one that includes at least a signature field (e.g., apersonal check, a driver's license, etc.).

The factors considered under the rule set 290 may include a number ofcounterfeit factors 292 and a number of forgery factors 294, each ofwhich may be evaluated by image analysis unit 52 of FIG. 1 using one ormore image processing techniques. The counterfeit factors 292 may relateto the look, presentation, format and/or structure of the document,while the forgery factors 294 may relate to the substance, style orformat of information entered in one or more fields of the document.

As seen in FIG. 4F, the counterfeit factors 292 may include: (1) whetherone or more absolute or relative dimensions and/or angles of thedocument, or of lines, illustrations, patterns, etc. shown on thedocument (excluding user-entered contents in fields such as thesignature line), are outside one or more predetermined tolerances; (2)whether one or more colors on the document are outside a predeterminedtolerance (e.g., color/frequency range); (3) whether one or more linethicknesses of the document (excluding user-entered field contents) areoutside one or more predetermined tolerances; and/or (4) whether one ormore fonts on the document (excluding user-entered field contents) areoutside one or more predetermined tolerances. For example, imageanalysis unit 52 may determine whether the ratio of the document lengthto the document width is within 0.1% of an expected value. As anotherexample, image analysis unit 52 may determine whether horizontal andvertical lines on the document are within 0.3 degrees of the horizontaland vertical edges of the document, respectively. As yet anotherexample, image analysis unit 52 may determine whether a font used for afield descriptor or other text on the document matches an expected font(e.g., by meeting a similarity threshold measured in any suitablemanner). In other embodiments, the counterfeit factors 292 may includemore, fewer and/or different factors than those shown in FIG. 4F.

The forgery factors 294 may include: (1) whether a signature entered ina signature field of the document match is outside a predeterminedtolerance (e.g., using any suitable signature recognition technique);(2) whether handwriting entered in one or more fields of the document isoutside a predetermined tolerance (e.g., by applying a suitablehandwriting recognition technique); and/or (3) whether the format ofinformation entered by a user in one or more fields does not match anexpected format (e.g., using “9.12.16” rather than the expected“9/12/2016,” as established based upon other documents known to havebeen populated and/or submitted by the purported applicant). In otherembodiments, the forgery factors 294 may include more, fewer and/ordifferent factors than those shown in FIG. 4F.

Generally, the data indicative of whether the circumstancescorresponding to counterfeit factors 292 and/or forgery factors 294 arepresent/true for a particular document may be included in the firstdocument image data 210 described above in connection with FIG. 3F.

As is also seen in FIG. 4F, each of the counterfeit factors 292 andforgery factors 294 may be associated with a particular score orweighting value. In the rule set 290 shown in FIG. 4F, a total score maybe calculated based upon which factors are, or are not, present. In someembodiments, certain factors may instead be associated with negativescores, and/or certain factors may be associated with metrics oralgorithms that determine how heavily those factors are weighed.

The rule set 290 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the likelihood that the document is fraudulent.Alternatively, the rule set 290 may output a separate total score,normalized score, probability, or other metric, for each of counterfeitfactors 292 and forgery factors 294, with the counterfeit metricindicating the likelihood that the document is a counterfeit and theforgery metric indicating the likelihood that the document wasfraudulently populated by someone other than the purported person (e.g.,by someone other than the person corresponding to the name, signature,address, etc. on the document). In the example shown in FIG. 4F, it canbe seen that larger scores generally correspond to a greater probabilitythat the document is fraudulent. In some embodiments, the rule set 290also includes one or more other types of factors not shown in FIG. 4F,and/or omits either counterfeit factors 292 or forgery factors 294.

V. Exemplary Methods for Fraud Detection & Classification

FIGS. 5-7 depict flow diagrams of various exemplary computer-implementedmethods that may be implemented by one or more components of AFSS 12 ofFIG. 1. In one embodiment, AFSS 12 implements all of the methodscorresponding to FIGS. 5-7. In other embodiments, AFSS 12 implementsonly a subset (e.g., one, two, etc.) of the methods corresponding toFIGS. 5-7. Each of the methods described below may be implemented byfraud detection/classification unit 36 of FIG. 1, for example.

A. Exemplary Methods for Facilitating Document-Related Fraud Detection

Referring now to FIG. 5, an exemplary computer-implemented method 300may be used to facilitate the detection of document-related fraud, e.g.,by winnowing the field of documents needing a more thorough (e.g.,manual) review or investigation. In the method 300, fraudulent documentdetection rules may be generated or updated at least by training amachine learning program (block 302), such as any of the types ofmachine learning programs discussed above in connection with ML rulegenerator 40 of FIG. 1 or process stage 84 of FIG. 2, for example. Themachine learning program may be trained using image data correspondingto a plurality of physical documents, and fraud determinations/labelseach corresponding to a respective one of those documents.

The physical documents and the fraudulent document detection rules maycorrespond to a first type of document, which may be a fairly generaltype (e.g., a personal check or other general type of financialinstrument, or a driver's license or other general type ofidentification document, etc.), or a more specific type (e.g., apersonal check associated with a particular bank, or a driver's licensefrom a particular state, etc.).

The rules generated or updated at block 302 may specify, for example, anacceptable tolerance for an absolute or relative measurement pertainingto a document (e.g., ratio of overall length to width, of variousdecorative or functional features depicted on the document, etc.). Asother examples, the rules may specify an acceptable font or set offonts, an acceptable pattern or set of patterns, an acceptable color orset (e.g., range) of colors, and so on. As yet another example, therules may specify one or more acceptable field locations (e.g.,placement of a signature line within the document, etc.).

First image data corresponding to an image of a first physical documentmay be received (block 304). The first physical document may be of thesame specific or general type as the documents used to train the machinelearning program at block 302 (e.g., a personal check, or a personalcheck associated with a particular bank, etc.). In some embodimentswhere fraud, or potential fraud, is detected substantially in real-time,the first image data is received from a point-of-sale computing deviceassociated with a merchant. For example, the merchant may, during orbefore a transaction, scan or photograph an identification card of acustomer, and the point-of-sale computing device (or another computingdevice of the merchant) may send the image of the identification card toa server implementing the method 300.

It may be determined, by applying the fraudulent document detectionrules to the first image data, that the first physical document is, ormay be (e.g., according to some probability level), fraudulent (block306). For example, the first physical document may be flagged asrequiring a more in-depth review of its authenticity. In otherscenarios, not represented by FIG. 5, it may instead be determined thatthe first physical document is not, or likely is not, fraudulent, (e.g.,such that it is not necessary to flag the application for furtherreview). In one embodiment, block 306 may occur substantially inreal-time upon receiving the first image data (e.g., from a merchantpoint-of-sale device).

An indication of whether the first physical document is, or may be,fraudulent may be caused to be displayed to one or more people via oneor more respective computing device user interfaces (block 308). Theindication may also specify additional information, such as a reason whythe document is suspect (e.g., the document is or may be counterfeit,and/or the contents in one or more fields of the document have been ormay have been forged, etc.). The indication may be sent to apoint-of-sale computing device of a merchant that provided the firstimage data, for example, to cause the device to display the indicationto the merchant or an employee of the merchant. Alternatively, or inaddition, the indication may be provided to a computing device of a cardissuer or other entity (e.g., to AFSS 12 of FIG. 1) to prompt a fullreview of the document (e.g., a manual investigation). In oneembodiment, block 308 may occur substantially in real-time uponreceiving the first image data. Block 308 may be implemented bynotification unit 56 of FIG. 1, for example.

In some embodiments, the method 300 may include one or more additionalblocks not shown in FIG. 5. For example, the method 300 may include anadditional block in which it is determined that the first physicaldocument corresponds to the same type as the documents used to train themachine learning program at block 302 (e.g., by using image processingto recognize various document features, such as locations and/or typesof different fields in the document, etc.). In one embodiment, block 306occurs in response to such a determination.

FIG. 6 illustrates a computer-implemented method 320 of identifyingfraudulent transactions, or financial instruments or identificationcards. The method 320 may include, via one or more processors and/ortransceivers (via wireless communication or data transmission over oneor more radio frequency links or wireless communication channels), (1)receiving a digital image of a signed financial instrument oridentification card (block 322); (2) analyzing the digital image usingoptical character recognition or other techniques to identify (i) a typeof financial instrument or identification card; and (ii) an originatingentity of the financial instrument or identification card (block 324);(3) determine the expected fields of the financial instrument oridentification card based upon the (i) type, and (ii) originatingentity, and/or allowable content, or an allowable range of content orcharacters (letters, numbers, etc.), for the expected field (block 326);(4) analyzing the digital image using optical character recognition orother techniques to identify actual fields on the financial instrumentor identification card (block 328); (5) determining if the expectedfields match the actual fields on the financial instrument oridentification card to determine if a fraudulent field exists on thefinancial instrument or identification card (block 330); and/or (6) if afraudulent field exists, then halting the transaction, and/or generatingand transmitting an electronic notification detailing that a fraudulentor unexpected field exists (block 332).

The method 320 may also include, (7) if a fraudulent field does notexist, then analyzing the digital image using optical characterrecognition or other techniques to identify actual characters or contentwithin the actual fields on the financial instrument or identificationcard (block 334); (8) comparing the actual characters or content withinthe actual fields with the allowable content, or the allowable range ofcontent or characters, for the corresponding expected field to determineif fraudulent characters or content are in an expected field (block336); and/or (9) if fraudulent content in an expected field exists,generating an electronic notification detailing the fraud or a why thefinancial instrument or identification card is suspicious, and/ortransmitting the electronic notification to a computing device of afinancial institution at which the financial instrument oridentification card is being presented (block 338) to facilitate haltinga transaction, flagging a financial instrument or identification cardfor further review, and/or identifying and reducing fraud.

In one embodiment, a computer-implemented method of identifyingfraudulent transactions, or financial instruments or identificationcards may be provided. The method may include (1) receiving, via one ormore processors and/or transceivers, a digital image of a signedfinancial instrument or identification card from a financial institutionor merchant computing terminal, such as via wireless communication ordata transmission over one or more radio links or wireless communicationchannels; (2) analyzing, via the one or more processors, the digitalimage using optical character recognition or other techniques toidentify (i) a type of financial instrument or identification card; and(ii) an originating entity of the financial instrument or identificationcard; (3) determine, via the one or more processors, the expected fieldsof the financial instrument or identification card based upon the (i)type, and (ii) originating entity; (4) analyzing, via the one or moreprocessors, the digital image using optical character recognition (OCR)or other techniques to identify actual fields on the financialinstrument or identification card; (5) determining, via the one or moreprocessors, if the expected fields match the actual fields on thefinancial instrument or identification card to determine if a fraudulentfield exists on the financial instrument or identification card (forinstance, an actual field may not match a size, height, or width of anexpected field, or an actual field may be at an angle or slant, ascompared to perfectly horizontal); (6) if a fraudulent field does exist,then generating, via the one or more processors, an electronicnotification indicating that a fraudulent field exists; and/or (7)transmitting, via the one or more processors and/or transceivers, theelectronic notification to the merchant computing terminal to providenotice of the fraudulent field.

The method may further include if a fraudulent field does not exist,then (i) determining or retrieving, allowable content, or an allowablerange of content or characters, for the expected fields; (ii) analyzing,via the one or more processors, the digital image using opticalcharacter recognition or other techniques to identify actual charactersor content within the actual fields on the financial instrument oridentification card; (iii) comparing, via the one or more processors,the actual characters or content within an actual field with theallowable content, or the allowable range of content or characters, forthe corresponding expected field to determine if fraudulent charactersor content are in an expected field (for instance, the font or size ofcharacters, letters, or number be incorrect, such as too large or toosmall in font size, or color of characters may be incorrect); (iv) iffraudulent content in an expected field exists, generating, via the oneor more processors, an electronic notification detailing the fraud or awhy the financial instrument or identification card is suspicious;and/or (v) transmitting, via the one or more processors and/ortransceivers, the electronic notification to a computing device of afinancial institution or merchant at which the financial instrument oridentification card is being presented to facilitate halting atransaction, and/or identifying and reducing fraud.

The identification card may be a social security card, and an expectedfield may be associated with a location of where a social securitynumber is printed, and the allowable content may be 9 numbers thatcomprise a social security number. The financial instrument may be apersonal check, and an expected field may be associated with a locationof where a bank routing number is printed, and the allowable content maybe a bank routing number. Additionally or alternatively, the financialinstrument may be a personal check, and an expected field may beassociated with a location of where a checking account is printed, andthe allowable content may be a checking account number.

The identification card may be a driver's license, and an expected fieldmay be associated with a location of where a driver license number isprinted, and the allowable content may be a driver's license number.Additionally or alternatively, the identification card may be apassport, and expected fields may be associated with a name, date ofbirth, and expiration date, and the allowable content may includecharacters or letters for a name field, and numbers for the date ofbirth and expiration date fields. The identification card may be asocial security card, and the allowable content may be a range ofpossible social security numbers available to an individual based upon alocation and date of their birth.

In one embodiment, a computer system configured to identify fraudulenttransactions, or financial instruments or identification cards may beprovided. The computer system may include one or more processors and/ortransceivers configured to: (1) receive, via wireless communication ordata transmission over one or more radio links or wireless communicationchannels, a digital image of a signed financial instrument oridentification card from a financial institution or merchant computingterminal; (2) analyze the digital image using optical characterrecognition or other techniques to identify (i) a type of financialinstrument or identification card; and (ii) an originating entity of thefinancial instrument or identification card; (3) determine the expectedfields of the financial instrument or identification card based upon the(i) type, and (ii) originating entity; (4) analyze the digital imageusing optical character recognition or other techniques to identifyactual fields on the financial instrument or identification card; (5)determine if the expected fields match the actual fields on thefinancial instrument or identification card to determine if a fraudulentfield exists on the financial instrument or identification card; (6) ifa fraudulent field does exist, then generate an electronic notificationindicating that a fraudulent field exists; and/or (7) transmit, viawireless communication or data transmission over one or more radio linksor wireless communication channels, the electronic notification to themerchant computing terminal to provide notice of the fraudulent field.

The one or more processors and/or transceivers may be further configuredto, if a fraudulent field does not exist, then determine or retrieveallowable content, or an allowable range of content or characters (suchas size of font or color, and type of characters, for allowablecontent), for the expected fields; analyze the digital image usingoptical character recognition or other techniques to identify actualcharacters or content within the actual fields on the financialinstrument or identification card; compare the actual characters orcontent within an actual field with the allowable content, or theallowable range of content or characters, for the corresponding expectedfield to determine if fraudulent characters or content are in anexpected field; if fraudulent content in an expected field exists (suchas letters in a numeric field, or incorrect font size or color forcharacters), generate an electronic notification detailing the fraud ora why the financial instrument or identification card is suspicious;and/or transmit, via wireless communication or data transmission overone or more radio links or wireless communication channels, theelectronic notification to a computing device of a financial institutionor merchant at which the financial instrument or identification card isbeing presented to facilitate halting a transaction, and/or identifyingand reducing fraud.

The identification card may be a passport, and expected fields may beassociated with a name, date of birth, and expiration date, and theallowable content may include characters or letters for a name field,and numbers for the date of birth and expiration date fields. Theidentification card may be a social security card, and the allowablecontent may be a range of possible social security numbers available toan individual based upon where and when they were born.

FIG. 7 illustrates a computer-implemented method 340 of identifyingfraudulent transactions and/or fraudulent signatures on financialinstruments or identification cards. The method 340 may include, via oneor more processors and/or transceivers (such as via wirelesscommunication or data transmission over one or more radio frequencylinks and/or wireless communication channels), (1) receiving a digitalimage of a signed financial instrument or identification card (block342); (2) analyzing the digital image using optical characterrecognition or other techniques to identify a name printed in font orset typeface on the financial instrument or identification card (block344); (3) analyzing the digital image using optical characterrecognition or other techniques to identify a current handwrittensignature on the financial instrument or identification card (block346); (4) retrieving a past known or trusted digital signature of personassociated with the name printed in font or set typeface on thefinancial instrument or identification card from a local or remotememory, or a third party database (block 348); (5) comparing the currenthandwritten signature with the past known or trusted digital signatureto determine a mismatch, or otherwise inputting the current handwrittensignature and/or trusted digital signature into a machine learningprogram trained to identify fraudulent signatures (block 350); (6) if amismatch is identified, generating an electronic notification detailingthe fraud or why the signature is suspicious, and/or transmitting theelectronic notification to a computing device of a financial institutionat which the financial instrument or identification card is beingpresented (block 352) to facilitate halting a transaction, and/oridentifying and reducing fraud.

VI. Exemplary System for Fraud Detection & Classification

FIG. 8 depicts an exemplary computer system 500 in which the techniquesdescribed herein may be implemented, according to one embodiment. Thecomputer system 500 of FIG. 8 may include a computing device in the formof a computer 510. Components of the computer 510 may include, but arenot limited to, a processing unit 520, a system memory 530, and a systembus 521 that couples various system components including the systemmemory 530 to the processing unit 520. The system bus 521 may be any ofseveral types of bus structures including a memory bus or memorycontroller, a peripheral bus, or a local bus, and may use any suitablebus architecture. By way of example, and not limitation, sucharchitectures include the Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus (also known as Mezzanine bus).

Computer 510 may include a variety of computer-readable media.Computer-readable media may be any available media that can be accessedby computer 510 and may include both volatile and nonvolatile media, andboth removable and non-removable media. By way of example, and notlimitation, computer-readable media may comprise computer storage mediaand communication media. Computer storage media may include volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media may include, but is not limited to, RAM, ROM, EEPROM,FLASH memory or other memory technology, CD-ROM, digital versatile disks(DVD) or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canaccessed by computer 510.

Communication media typically embodies computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave or other transport mechanism, and mayinclude any information delivery media. The term “modulated data signal”means a signal that has one or more of its characteristics set orchanged in such a manner as to encode information in the signal. By wayof example, and not limitation, communication media may include wiredmedia such as a wired network or direct-wired connection, and wirelessmedia such as acoustic, radio frequency (RF), infrared and otherwireless media. Combinations of any of the above are also includedwithin the scope of computer-readable media.

The system memory 530 may include computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 531and random access memory (RAM) 532. A basic input/output system 533(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 510, such as during start-up, istypically stored in ROM 531. RAM 532 typically contains data and/orprogram modules that are immediately accessible to, and/or presentlybeing operated on, by processing unit 520. By way of example, and notlimitation, FIG. 8 illustrates operating system 534, applicationprograms 535, other program modules 536, and program data 537.

The computer 510 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 8 illustrates a hard disk drive 541 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 551that reads from or writes to a removable, nonvolatile magnetic disk 552,and an optical disk drive 555 that reads from or writes to a removable,nonvolatile optical disk 556 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 541 may be connected to thesystem bus 521 through a non-removable memory interface such asinterface 540, and magnetic disk drive 551 and optical disk drive 555may be connected to the system bus 521 by a removable memory interface,such as interface 550.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 8 provide storage of computer-readableinstructions, data structures, program modules and other data for thecomputer 510. In FIG. 8, for example, hard disk drive 541 is illustratedas storing operating system 544, application programs 545, other programmodules 546, and program data 547. Note that these components can eitherbe the same as or different from operating system 534, applicationprograms 535, other program modules 536, and program data 537. Operatingsystem 544, application programs 545, other program modules 546, andprogram data 547 are given different numbers here to illustrate that, ata minimum, they are different copies. A user may enter commands andinformation into the computer 510 through input devices such as cursorcontrol device 561 (e.g., a mouse, trackball, touch pad, etc.) andkeyboard 562. A monitor 591 or other type of display device is alsoconnected to the system bus 521 via an interface, such as a videointerface 590. In addition to the monitor, computers may also includeother peripheral output devices such as printer 596, which may beconnected through an output peripheral interface 595.

The computer 510 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer580. The remote computer 580 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andmay include many or all of the elements described above relative to thecomputer 510, although only a memory storage device 581 has beenillustrated in FIG. 8. The logical connections depicted in FIG. 8include a local area network (LAN) 571 and a wide area network (WAN)573, but may also include other networks. Such networking environmentsare commonplace in hospitals, offices, enterprise-wide computernetworks, intranets and the Internet.

When used in a LAN networking environment, the computer 510 is connectedto the LAN 571 through a network interface or adapter 570. When used ina WAN networking environment, the computer 510 may include a modem 572or other means for establishing communications over the WAN 573, such asthe Internet. The modem 572, which may be internal or external, may beconnected to the system bus 521 via the input interface 560, or otherappropriate mechanism. The communications connections 570, 572, whichallow the device to communicate with other devices, are an example ofcommunication media, as discussed above. In a networked environment,program modules depicted relative to the computer 510, or portionsthereof, may be stored in the remote memory storage device 581. By wayof example, and not limitation, FIG. 8 illustrates remote applicationprograms 585 as residing on memory device 581.

The techniques for detecting and/or classifying fraud described abovemay be implemented in part or in their entirety within a computer systemsuch as the computer system 500 illustrated in FIG. 8. The computer 510may be included in AFSS 12 of FIG. 1, for example, and/or the remoteapplication programs 585 may include one or more applications of eitherFAMS 14, one of cardholder computing device 20, one of merchantcomputing systems 22, or a computing device of other sources 24.Moreover, the functionality of fraud detection/classification unit 36 ofFIG. 1 may be implemented by one or more of application programs 535and/or other program modules 536. As another example, ML rules database58, account holder behaviors database 60 and/or chargeback rulesdatabase 62 of FIG. 1 may be stored in hard disk drive 541 (e.g., asprogram data 547), magnetic disk 552 and/or optical disk drive 555,and/or the data retrieved by fraud detection/classification unit 36 ofFIG. 1 may be stored in hard disk drive 541 (e.g., as program data 547)and/or RAM 532 (e.g., as program data 537).

VII. Exemplary Method Embodiments

In another aspect, a computer-implemented method, implemented in one ormore servers or other computing devices, of facilitating detection ofdocument-related fraud may include (1) generating or updating, by one ormore processors of the one or more servers, fraudulent documentdetection rules at least by training a machine learning program using atleast (i) image data corresponding to a plurality of physical documents,and (ii) fraud determinations each corresponding to a respective one ofthe plurality of physical documents, wherein the plurality of physicaldocuments and the fraudulent document detection rules may correspond toa first type of document; (2) receiving, by the one or more processors,first image data corresponding to an image of a first physical document,wherein the first physical document may correspond to the first type ofdocument; (3) determining, by the one or more processors applying thefraudulent document detection rules to the first image data, that thefirst physical document is, or may be, fraudulent; and/or (4) causing,by the one or more processors, an indication of whether the firstphysical document is, or may be, fraudulent to be displayed to one ormore people via one or more respective computing device user interfaces.The method may include additional, fewer or alternative actions, such asany of those discussed elsewhere herein.

For instance, the method may further include determining, by the one ormore processors, that the first physical document corresponds to thefirst type of document, and/or the one or more processors may apply thefraudulent document detection rules to the first physical document inresponse to determining that the first physical document corresponds tothe first type of document.

Additionally or alternatively, generating fraudulent document detectionrules may include determining an acceptable tolerance for an absolute orrelative measurement.

Additionally or alternatively, generating fraudulent document detectionrules may include determining (i) an acceptable font or set of fonts,(ii) an acceptable pattern or set of patterns, and/or (iii) anacceptable color or set of colors.

Additionally or alternatively, generating fraudulent document detectionrules may include determining an acceptable field location. Additionallyor alternatively, the first type of document may be a financialinstrument or an identification card.

Additionally or alternatively, both (i) determining that the firstphysical document is, or may be, fraudulent, and (ii) causing theindication of whether the first physical document is, or may be,fraudulent to be displayed, may occur substantially in real-time uponreceiving the first image data. Additionally or alternatively, causingthe indication of whether the first physical document is, or may be,fraudulent to be displayed may include causing a point-of-sale computingdevice associated with a merchant to display the indication.

VIII. Exemplary System Embodiments

In another aspect, a computer system for facilitating detection ofdocument-related fraud may include (1) a rules database configured tostore fraudulent document detection rules; (2) one or more processors;and/or (3) a non-transitory memory. The non-transitory memory storesinstructions that, when executed by the one or more processors, maycause the one or more processors to (1) generate or update thefraudulent document detection rules at least by training a machinelearning program using at least (i) image data corresponding to aplurality of physical documents, and (ii) fraud determinations eachcorresponding to a respective one of the plurality of physicaldocuments, wherein the plurality of physical documents and thefraudulent document detection rules may correspond to a first type ofdocument; (2) receive first image data corresponding to an image of afirst physical document, wherein the first physical document maycorrespond to the first type of document; (3) determine, by applying thefraudulent document detection rules stored in the rules database to thefirst image data, that the first physical document is, or may be,fraudulent; and/or (4) cause an indication of whether the first physicaldocument is, or may be, fraudulent to be displayed to one or more peoplevia one or more respective computing device user interfaces. The systemmay include additional, fewer or alternative components, features and/orfunctionality, such as any of those discussed elsewhere herein.

For instance, the instructions may further cause the one or moreprocessors to determine that the first physical document corresponds tothe first type of document, and/or the instructions may cause the one ormore processors to apply the fraudulent document detection rules to thefirst physical document in response to determining that the firstphysical document corresponds to the first type of document.Additionally or alternatively, the fraudulent document detection rulesmay specify an acceptable tolerance for an absolute or relativemeasurement. Additionally or alternatively, the fraudulent documentdetection rules may specify (i) an acceptable font or set of fonts, (ii)an acceptable pattern or set of patterns, and/or (iii) an acceptablecolor or set of colors. Additionally or alternatively, the fraudulentdocument detection rules may specify an acceptable field location.

Additionally or alternatively, the first type of document may be afinancial instrument or an identification card. Additionally oralternatively, the instructions may cause the one or more processors toboth (i) determine that the first physical document is, or may be,fraudulent, and (ii) cause the indication of whether the first physicaldocument is, or may be, fraudulent to be displayed, substantially inreal-time upon receiving the first image data.

IX. Exemplary Computer-Readable Medium Embodiments

In another aspect, a non-transitory, computer-readable medium storesinstructions that, when executed by one or more processors, may causethe one or more processors to (1) generate or update fraudulent documentdetection rules at least by training a machine learning program using atleast (i) image data corresponding to a plurality of physical documents,and (ii) fraud determinations each corresponding to a respective one ofthe plurality of physical documents, wherein the plurality of physicaldocuments and the fraudulent document detection rules may correspond toa first type of document; (2) receive first image data corresponding toan image of a first physical document, the first physical documentcorresponding to the first type of document; (3) determine, by applyingthe fraudulent document detection rules to the first physical document,that the first physical document is, or may be, fraudulent; and/or (4)cause an indication of whether the first physical document is, or maybe, fraudulent to be displayed to one or more people via one or morerespective computing device user interfaces. The computer-readablemedium may store instructions that include additional, fewer oralternative actions, such as any of those discussed elsewhere herein.

For instance, the instructions may further cause the one or moreprocessors to determine that the first physical document corresponds tothe first type of document, and/or the instructions cause the one ormore processors to apply the fraudulent document detection rules to thefirst physical document in response to determining that the firstphysical document corresponds to the first type of document.Additionally or alternatively, the fraudulent document detection rulesmay specify an acceptable tolerance for an absolute or relativemeasurement. Additionally or alternatively, the fraudulent documentdetection rules may specify (i) an acceptable font or set of fonts, (ii)an acceptable pattern or set of patterns, and/or (iii) an acceptablecolor or set of colors. Additionally or alternatively, the fraudulentdocument detection rules may specify an acceptable field location.

X. Additional Considerations

The following additional considerations apply to the foregoingdiscussion. Throughout this specification, plural instances mayimplement operations or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. These and othervariations, modifications, additions, and improvements fall within thescope of the subject matter herein.

1. A computer-implemented method of identifying fraudulent transactions,fraudulent financial instruments, or fraudulent identification cards,comprising: storing associations of a plurality of types of signedfinancial instruments or identification cards and a plurality oforiginating entities of the plurality of types of the signed financialinstruments or identification cards with information about expectedfields of the plurality of types of signed financial instruments oridentification cards, the information about the expected fieldscomprising one or more physical field locations of the expected fieldson the associated signed financial instruments or identification cards,an identification of a type of content associated with the expectedfields, and an expected font of textual content associated with theexpected fields; receiving, by one or more processors, a digital imageof a signed financial instrument or identification card; determining, bythe one or more processors and from the digital image, (i) a type of thesigned financial instrument or identification card and (ii) anoriginating entity of the signed financial instrument or identificationcard; determining, by the one or more processors, at least one expectedfield of the signed financial instrument or identification card basedupon (i) the type, (ii) the originating entity, and (iii) theassociations; identifying, by the one or more processors, an actualfield in the digital image; determining, by the one or more processors,whether a first font used for textual content of the actual fieldmatches the expected font; and determining, by the one or moreprocessors and based on whether the first font matches the expectedfont, whether the actual field is a fraudulent field.
 2. (canceled) 3.The computer-implemented method of claim 1, further comprising:determining allowable content for the at least one expected field; andcomparing, by the one or more processors, content in the actual field tothe allowable content, wherein: the identification card is a socialsecurity card; the expected fields include a field associated with alocation of where a social security number is printed; and the allowablecontent is at least one of nine numbers that comprise a social securitynumber or a range of possible social security numbers available to anindividual based upon a location and date of their birth.
 4. Thecomputer-implemented method of claim 1, further comprising: determiningallowable content for the at least one expected field; and comparing, bythe one or more processors, content in the actual field to the allowablecontent, wherein: the signed financial instrument is a personal check;the expected fields include a field associated with a location of wherea bank routing number is printed; and the allowable content is a bankrouting number.
 5. The computer-implemented method of claim 1, furthercomprising: determining allowable content for the at least one expectedfield; and comparing, by the one or more processors, content in theactual field to the allowable content, wherein: the signed financialinstrument is a personal check; the at least one expected field includesa field associated with a location of where a checking account number isprinted; and the allowable content is a checking account number.
 6. Thecomputer-implemented method of claim 1, further comprising: determiningallowable content for the at least one expected field; and comparing, bythe one or more processors, content in the actual field to the allowablecontent, wherein: the identification card is a driver's license; the atleast one expected field includes a field associated with a location ofwhere a driver's license number is printed; and the allowable content isa driver's license number.
 7. The computer-implemented method of claim1, further comprising: determining allowable content for the at leastone expected field; and comparing, by the one or more processors,content in the actual field to the allowable content, wherein: theidentification card is a passport; the expected fields include a fieldassociated with a name, date of birth, and expiration date; and theallowable content includes (i) characters or letters for a name field,and (ii) numbers for the date of birth and expiration date fields. 8.(canceled)
 9. A computer system for identifying fraudulent transactions,financial instruments, or identification cards, wherein the computersystem comprises one or more transceivers and one or more processorsconfigured to: store associations of a plurality of types of signedfinancial instruments or identification cards and a plurality oforiginating entities of the plurality of types of the signed financialinstruments or identification cards with information about expectedfields of the plurality of types of signed financial instruments oridentification cards, the information about the expected fieldscomprising one or more physical field locations of content of theexpected fields on the associated signed financial instruments oridentification cards, an identification of a type of content the contenton the associated signed financial instruments or identification cardsassociated with the expected fields, and an expected font of textualcontent associated with the expected fields; receive, via the one ormore transceivers and one or more radio links, a digital image of asigned financial instrument or identification card; determine, from thedigital image, (i) a type of the signed financial instrument oridentification card and (ii) an originating entity of the signedfinancial instrument or identification card; determine at least oneexpected field of the signed financial instrument or identification cardbased upon (i) the type, (ii) the originating entity, and (iii) theassociations; identify an actual field in the digital image; determinewhether a first font used for textual content of the actual fieldmatches the expected font; and determine, based on whether the firstfont matches the expected font, whether the actual field is a fraudulentfield.
 10. The computer system of claim 9, wherein the one or moreprocessors are further configured to: determine allowable content forthe at least one expected field; and compare content in the actual fieldto the allowable content, wherein: the identification card is a socialsecurity card; the at least one expected field includes a fieldassociated with a location of where a social security number is printed;and the allowable content is at least one of nine numbers that comprisea social security number or a range of possible social security numbersavailable to an individual based upon at least one of a location ofbirth or a date of birth of the individual.
 11. The computer system ofclaim 9, wherein the one or more processors are further configured to:determine allowable content for the at least one expected field; andcompare content in the actual field to the allowable content, wherein:the signed financial instrument is a personal check; the at least oneexpected field includes a field associated with a location of where abank routing number is printed; and the allowable content is a bankrouting number.
 12. The computer system of claim 9, wherein the one ormore processors are further configured to: determine allowable contentfor the at least one expected field; and compare content in the actualfield to the allowable content, wherein: the signed financial instrumentis a personal check; the at least one expected field includes a fieldassociated with a location of where a checking account is printed; andthe allowable content is a checking account number.
 13. The computersystem of claim 9, wherein the one or more processors are furtherconfigured to: determine allowable content for the at least one expectedfield; and compare content in the actual field to the allowable content,wherein: the identification card is a driver's license; the at least oneexpected field includes a field associated with a location of where adriver's license number is printed; and the allowable content is adriver's license number.
 14. The computer system of claim 9, wherein theone or more processors are further configured to: determine allowablecontent for the at least one expected field; and compare content in theactual field to the allowable content, wherein: the identification cardis a passport; the at least one expected field includes a fieldassociated with a name, date of birth, and expiration date; and theallowable content includes (i) characters or letters for a name field,and (ii) numbers for the date of birth and expiration date fields. 15.(canceled)
 16. A non-transitory, computer-readable medium storinginstructions that, when executed by one or more processors, cause theone or more processors to: store associations of a plurality of types ofsigned financial instruments or identification cards and a plurality oforiginating entities of the plurality of types of the signed financialinstruments or identification cards with information about expectedfields of the plurality of types of signed financial instruments oridentification cards, the information about the expected fieldscomprising one or more physical field locations of content of theexpected fields on the associated signed financial instruments oridentification cards, an identification of a type of content the contenton the associated signed financial instruments or identification cardsassociated with the expected fields, and an expected font of textualcontent associated with the expected fields; receive a digital image ofa signed financial instrument or identification card; determine, fromthe digital image, (i) a type of the signed financial instrument oridentification card, and (ii) an originating entity of the signedfinancial instrument or identification card; determine at least oneexpected field of the signed financial instrument or identification cardbased upon (i) the type, (ii) the originating entity, and (iii) theassociations; identify an actual field in the digital image; determinewhether a first font used for textual content of the actual fieldmatches the expected font; and determine, based on whether the firstfont matches the expected font, whether the actual field is a fraudulentfield.
 17. The non-transitory, computer-readable medium of claim 16,wherein the instructions further cause the one or more processors to:determine allowable content for the at least one expected field; andcompare content in the actual field to the allowable content, wherein:the identification card is a social security card; the at least oneexpected field includes a field associated with a location of where asocial security number is printed; and the allowable content is ninenumbers that comprise a social security number.
 18. The non-transitory,computer-readable medium of claim 16, wherein the instructions furthercause the one or more processors to: determine allowable content for theat least one expected field; and compare content in the actual field tothe allowable content, wherein: the signed financial instrument is apersonal check; the expected field includes a field associated with alocation of where a bank routing number is printed; and the allowablecontent is a bank routing number.
 19. The non-transitory,computer-readable medium of claim 16, wherein the instructions furthercause the one or more processors to: determine allowable content for theat least one expected field; and compare content in the actual field tothe allowable content, wherein: the signed financial instrument is apersonal check; the expected field includes a field associated with alocation of where a checking account is printed; and the allowablecontent is a checking account number.
 20. The non-transitory,computer-readable medium of claim 16, wherein the instructions furthercause the one or more processors to: determine allowable content for theat least one expected field; and compare content in the actual field tothe allowable content, wherein: the identification card is a driver'slicense; the at least one expected field includes a field associatedwith a location of where a driver's license number is printed; and theallowable content is a driver's license number.
 21. Thecomputer-implemented method of claim 1, further comprising: generating,by the one or more processors and in response to determining that theactual field is a fraudulent field, an electronic notificationindicating that the fraudulent field exists on the signed financialinstrument or identification card, and transmitting, by the one or moreprocessors and one or more transceivers, the electronic notification toa merchant computing terminal to provide notice of the fraudulent field.22. The computer-implemented method of claim 1, further comprising:determining, by the one or more processors and in response todetermining that the actual field is not a fraudulent field, allowablecontent for the at least one expected field; identifying, by the one ormore processors and in the digital image, actual content within theactual field; determining, by the one or more processors, that theactual content is different from the allowable content; generating, bythe one or more processors, an electronic notification indicating thatthe signed financial instrument or identification card is suspicious,and transmitting, by the one or more processors and one or moretransceivers, the electronic notification to a computing device of afinancial institution or merchant at which the signed financialinstrument or identification card is being presented.
 23. Thecomputer-system of claim 9, wherein one or more processors are furtherconfigured to: determine, in response to determining that the actualfield is not a fraudulent field, allowable content for the at least oneexpected field; identify, in the digital image, content within theactual field; determine that the content is different from the allowablecontent; generate an electronic notification indicating that the signedfinancial instrument or identification card is suspicious, and transmitthe electronic notification to a computing device of a financialinstitution or merchant at which the signed financial instrument oridentification card is being presented.